Problem with mksurfdata_map for smallville landuse.timeseries

[ekluzek]

Erik Kluzek < erik > - 2017-01-12 11:19:20 -0700
Bugzilla Id: 2400
Bugzilla CC: dlawren, rfisher, sacks,

With clm4_5_14_r215 I get the following when trying to run the smallville landuse.timeseries site in mksurfdata_map

The command is...

./mksurfdata.pl -no_surfdata -glc_nec 0 -y 1850-1855 -r 1x1_smallvilleIA -pft_idx 17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78 -pft_frc 6.5,1.5,1.6,1.7,1.8,1.9,1.5,1.6,1.7,1.8,1.9,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5 -dynpft single_point_dynpft_files/landuse_timeseries_smallvilleIA_hist_simyr1850-1855.txt

It fails in harvest with...

sum over domain of cft 77 1.50000000000000
sum over domain of cft 78 1.50000000000000

fsurdat is blank: skipping writing surface dataset
creating dynamic land use dataset
SKIP: PFT_LULCC
SKIP: CFT_LULCC
(OPNFIL): Successfully opened file
single_point_dynpft_files/landuse_timeseries_smallvilleIA_hist_simyr1850-1855.t
xt on unit= 98
forrtl: severe (24): end-of-file during read, unit -5, file Internal List-Directed Read
Image PC Routine Line Source
mksurfdata_map 00000000004A3394 Unknown Unknown Unknown
mksurfdata_map 00000000004BF39F Unknown Unknown Unknown
mksurfdata_map 00000000004BDE2E Unknown Unknown Unknown
mksurfdata_map 0000000000430A5C mkharvestmod_mp_m 1080 mkharvestMod.F90
mksurfdata_map 000000000046B182 MAIN__ 1113 mksurfdat.F90
mksurfdata_map 000000000040975E Unknown Unknown Unknown
libc.so.6 0000003DD441ED5D Unknown Unknown Unknown
mksurfdata_map 0000000000409669 Unknown Unknown Unknown

this is probably a fairly simple problem as harvest should be set to zero for the smallville case.

[ekluzek]

Erik Kluzek < erik > - 2017-04-30 17:20:09 -0600

The problem is that now there are more harvest variables and some of them are 2D. So this part of the code...

  read(substring,*) oride_harv(1:numharv-1)
  call shr_string_betweenTags( string, graz_start, graz_end, substring, rc )
  if ( rc /= 0 )then
     write(6,*) subname//'Trouble finding grazing start end tags'
     call abort()
  end if
  read(substring,*) oride_harv(numharv)
  if ( harvest_fieldnames(numharv) /= 'GRAZING' )then
     write(6,*) subname, ' grazing is NOT last field as was expected'
     call abort()
  end if

Doesn't work for the new situation where numharv = 9, and it's trying to read this..

single_point_dynpft_files/landuse_timeseries_smallvilleIA_hist_simyr1850-1855.txt

<pft_f>100</pft_f><pft_i>13</pft_i>0,0,0,0,00

The new types added are: FERTNITRO_CFT, UNREPRESENTED_PFT_LULCC, and UNREPRESENTED_CFT_LULCC.

We could assume they were all zero, or have each of them in a separate tag for the full PFT or CFT array as appropriate for each variable. And grazing needs to not be the last one expected as the code is doing now. This might need to be on it's own line as well.

[ekluzek]

Bill Sacks < sacks > - 2017-12-15 13:27:28 -0700

This bug also causes problems for the smallville surface datasets. I have generated new smallville surface datasets for use in my branch where we always use glc_nec=10; I have reproduced this problem from the trunk (clm4_5_18_r268): If you create a smallville surface dataset from the new code, this test dies:

ERS_Lm20_Mmpi-serial.1x1_smallvilleIA.I2000Clm50BgcCropGs.yellowstone_pgi.clm-monthly

with

 nstep =      20638   TS =   291.686611321149996
 nbalance warning           12   1.4411518807585587E+017
   1.0416666267607459E+033
 inputs,ffix,nfix,ndep =    9.0350776681062120E-006    0.000000000000000
   7.1360665356088945E-005
 outputs,lch,roff,dnit =    7.1251042104887423E-004   5.0115995744049076E-004
   1.8369184307236034E-006
 nbalance warning           13   1.4411518807585587E+017
   1.0416666267607459E+033
 inputs,ffix,nfix,ndep =    8.1483508116845273E-006    0.000000000000000
   7.1360665356088945E-005
 outputs,lch,roff,dnit =    9.4723224351003603E-005   2.3798922889612187E-004
   5.3013520824923123E-007
 column nbalance error    =    1.4411518807585587E+017           13
 Latdeg,Londeg            =     40.68780000000000
    267.0228000000000
 begnb                    =     1924.662070527338
 endnb                    =    1.0416666267607459E+033
 delta store              =    1.0416666267607459E+033
 input mass               =    1.0416666267607461E+033
 output mass              =    4.6651752730440522E-004
 net flux                 =    1.0416666267607461E+033
 inputs,ffix,nfix,ndep    =    8.1483508116845273E-006
    0.000000000000000        7.1360665356088945E-005
 outputs,ffix,nfix,ndep   =    9.4723224351003603E-005
   2.3798922889612187E-004   5.3013520824923123E-007
 ENDRUN:
 ERROR in /glade2/scratch2/sacks/cesm_code/clm4_5_18_r268/components/clm/src/biogeochem/CNBalanceCheckMod.F90 at line 351

It looks like the problem is that UNREPRESENTED_PFT_LULCC and UNREPRESENTED_CFT_LULCC are 1e36 in the file.

This test isn't very important (and I realized it needs to be reworked to test what it says it's testing), so I'm going to let it fail for now.

Other smallville tests are okay right now, because they still point to the old landuse_timeseries file (despite pointing to a new fsurdat): the problem with this one is that there is no landuse_timeseries file so these messed up fields on the surface dataset cause problems.

[ekluzek]

Note that both gnu and intel have the same balance error reported above.

ERS_Lm20_Mmpi-serial.1x1_smallvilleIA.I2000Clm50BgcCropGs.cheyenne_gnu.clm-monthly
ERS_Lm20_Mmpi-serial.1x1_smallvilleIA.I2000Clm50BgcCropGs.cheyenne_intel.clm-monthly

[billsacks]

The issue with the surface dataset for non-transient cases, which causes a balance check error (see #158 (comment)) is also documented in #203 . Let's keep this issue for dealing with the creation of the smallville landuse.timeseries file, and use #203 for the smallville surface dataset (because I think I can come up with a simple workaround for the latter).

[ekluzek]

We are going to resolve this issue with #1673 in subset data rather than in mksurfdata.pl.

[ekluzek]

Closing this as this will be solved a different way with subset_data.