Error in running case with use_c13 on

[jiamengl]

Hi,

I tried to run a Bgc case 2000_DATM%GSWP3v1_CLM50%BGC-CROP_SICE_SOCN_MOSART_SGLC_SWAV with use_c13 set as .true. However, there appeared error like this in cesm.log:

set_curr_delta ERROR: found unexpected non-zero delta mid-year
434: Dribbler name: hrv_xsmrpool_to_atm_c_13
434: i, delta = 2 NaN
434: Start of time step date (yr, mon, day, tod) = 1990 1
434: 11 46800
434: This indicates that some non-zero flux was generated at a time step
434: other than the first time step of the year, which this dribbler was told not to
434: expect.
434: If this non-zero mid-year delta is expected, then you can suppress this error
434: by setting allows_non_annual_delta to .true. when constructing this dribbler.

Can anyone help me with this? I didn't really change anything in the code and other setting.

 

[oleson]

Hi, you'll have to provide some additional information in order for me to try and reproduce this. See here, thanks:

Information to include in help requests

When you are posting to the forums because you want help with an issue, please include as much of the following information as possible. Please read the following before submitting a help request: Check the CESM support policy, and particularly the list of currently-supported versions at the...

bb.cgd.ucar.edu

 

[jiamengl]

Hi, you'll have to provide some additional information in order for me to try and reproduce this. See here, thanks:

Information to include in help requests

When you are posting to the forums because you want help with an issue, please include as much of the following information as possible. Please read the following before submitting a help request: Check the CESM support policy, and particularly the list of currently-supported versions at the...

bb.cgd.ucar.edu

Hi I am running ctsm5.1.dev098

I just created a case 2000_DATM%GSWP3v1_CLM50%BGC-CROP_SICE_SOCN_MOSART_SGLC_SWAV (resolution: f19_g17) and add 'use_c13=.true.' in user_nl_clm. Nothing change else.

 

[oleson]

I can't reproduce your case and run right now because our machines are down so I can't replicate your exact error, but I see that the initial file that is provided out of the box for this compset and resolution:

/glade/p/cesmdata/cseg/inputdata/lnd/clm2/initdata_map/clmi.I2000Clm50BgcCrop.2011-01-01.1.9x2.5_gx1v7_gl4_simyr2000_c190312.nc

doesn't have isotope fields on it, so when you turn on isotopes it will cause a problem, presumably the one you are seeing.

 

[oleson]

Our machines are now up. I ran your case successfully for 5 days.
I see that your error occurred at
Start of time step date (yr, mon, day, tod) = 1990 11 46800
The default start is 2000-01-01.
Did you change something else?

 

[jiamengl]

Our machines are now up. I ran your case successfully for 5 days.
I see that your error occurred at
Start of time step date (yr, mon, day, tod) = 1990 11 46800
The default start is 2000-01-01.
Did you change something else?

Yes, I changed the rundate from 1990-01-01 and tried to run for 10 years.
Actually I tried another case, to first run without C13 for 1 year, and then use the restart file as finidat. In this case, it can run successfully. But I couldn't figure out why this can succeed but the default initial file failed.

 

[oleson]

My mistake sorry, actually, my case failed with a similar error but at the default start date:

Start of time step date (yr, mon, day, tod) = 2000 1 12 3600

In your successful case, do the isotope history fields look reasonable? Do you see any NaNs or other unreasonable values?

 

[jiamengl]

My mistake sorry, actually, my case failed with a similar error but at the default start date:

Start of time step date (yr, mon, day, tod) = 2000 1 12 3600

In your successful case, do the isotope history fields look reasonable? Do you see any NaNs or other unreasonable values?

Hi I checked C13_TOTVEGC, and I think it looks normal. There are NaN values, but I think appears for non-land pixels

 

[oleson]

Ok, thanks. It may be that "missing" or "FillValues" may appear to be NaNs in certain analysis languages. In the one I use they appear as 1.e36.
So, I guess your approach works.
See here for a discussion of some recent problems related to this that we've had with isotopes:

C isotope fields can have garbage values starting in ctsm5.1.dev008 · Issue #1358 · ESCOMP/CTSM

Brief summary of bug Ever since ctsm5.1.dev008, the C isotope fields in this test ERP_D_Ld10_P36x2.f10_f10_musgs.IHistClm51BgcCropGs.cheyenne_intel.clm-ciso_decStart or its equivalent (it has chang...

github.com