Guidance on Running with LME datasets with CESM2.1.3 (CLM5)

[oleson]

Yes, it is.

 

[wvsi3w]

Yes, it is.

Thank you very much dear Keith for your answer.
I tested the case with these changes into my user_nl_clm and thankfully it did work (there is no need to assign the surfdata file as it is already set):

soil_layerstruct= '23SL_3.5m'
use_init_interp = .true.

check_dynpft_consistency =.false.
do_transient_crops=.false.
do_transient_pfts=.false.
flanduse_timeseries=' '

So, until here I have set land cover change to be constant (1850), landuse_timeseries are also omitted.
before I ask my question I need to refer to this quote from you regarding the dtlimit and monthly dataset. I have talked with my supervisors and couple of other colleagues and we decided to stick with the monthly data as land has a longer memory than atmosphere and monthly can be accepted for the goal of our project. However, I have a mini question about that dtlimit which I couldn't figure out why 3hourly is equal to 1.5 and monthly is 1.e36? what is 1.5 and what is 1.e36? is this 1x e to the power of 36? is it seconds in a month (doubt it), hours???

Back to my main question, now that almost everything is set for a spin-down simulation using data from year 500, I need to know if there is a way to set CO2 for that year in the model because the plot below is from the reference where my dataset has used its GHGs and I want to have similar CO2 as well. It is showing almost constant value of CO2 from year 500 to 1850 (I guess it is 275 ppm). The CLM5 documentation shows ways of running with historical CO2, but this period that I am trying to run (and trying to spin-down) I believe is pre-historical.



From (Meinhausen et al., 2017): doi:10.5194/gmd-10-2057-2017

Therefore, I think we need to have either a constant value for CO2 (like 275ppm) but I don't know how to set it in my case (is it supposed to be set in user_nl_clm as well? and how?), or we can have a transient CO2 file because I see this file "fco2_datm_global_simyr_1750-2014_CMIP6_c180929.nc" exist in the CO2 folder of my input data and I think we should either change it or set some option in the namelists to ignore this file?

Another concern is that there are other inputdata for land "urbandata", "firedata", ... that are for the historical period and not pre-historical. Should we set them off somehow as well or we can ignore these files for my case? how about the solar file inside "/inputdata/atm/cam/solar/" (SolarForcing1995-2005avg_c160929.nc)? Can we ignore this one as well or should we turn this one off as well?

Thank you in advance for your support.

 

[wvsi3w]

and how about aerosol?

 

[oleson]

Regarding dtlimit, I found this documentation:


<entry id="dtlimit" per_stream_entry="true">
<type>real(30)</type>
<category>streams</category>
<group>shr_strdata_nml</group>
<desc>
array (up to 30 elements) of delta time ratio limits placed on the
time interpolation associated with the array of streams. this real
value causes the model to stop if the ratio of the running maximum
delta time divided by the minimum delta time is greater than the
dtlimit for that stream. for instance, with daily data, the delta
time should be exactly one day throughout the dataset and the computed
maximum divided by minimum delta time should always be 1.0. for
monthly data, the delta time should be between 28 and 31 days and the
maximum ratio should be about 1.1. the running value of the delta
time is computed as data is read and any wraparound or cycling is also
included. this input helps trap missing data or errors in cycling.
to turn off trapping, set the value to 1.0e30 or something similar.
</desc>

The error you got was:

(shr_strdata_advance) ERROR: for stream 1
(shr_strdata_advance) ERROR: dt limit1 62.0000000000000
28.0000000000000 1.50000000000000
(shr_strdata_advance) ERROR: dt limit2 18500201 0 18500301 0

And the corresponding code is:

SDAT%dtmin(n) = min(SDAT%dtmin(n),dtime)
SDAT%dtmax(n) = max(SDAT%dtmax(n),dtime)
if ((SDAT%dtmax(n)/SDAT%dtmin(n)) > SDAT%dtlimit(n)) then
write(logunit,*) trim(subname),' ERROR: for stream ',n
write(logunit,*) trim(subName),' ERROR: dt limit1 ',SDAT%dtmax(n),SDAT%dtmin(n),SDAT%dtlimit(n)
write(logunit,*) trim(subName),' ERROR: dt limit2 ',SDAT%ymdLB(n),SDAT%todLB(n), &
SDAT%ymdUB(n),SDAT%todUB(n)
call shr_sys_abort(trim(subName)//' ERROR dt limit for stream')
endif

So, 62/28 = 2.2 which is > 1.5

My suggestion was to set dtlimit to something large to avoid this, but looking at this closer this would seem to indicate that you may have a 62 day gap in your forcing data somewhere? I'd look at the time stamps in your forcing files. Maybe your monthly time stamps should be in the middle of the month?

 

[wvsi3w]

Regarding dtlimit, I found this documentation:


<entry id="dtlimit" per_stream_entry="true">
<type>real(30)</type>
<category>streams</category>
<group>shr_strdata_nml</group>
<desc>
array (up to 30 elements) of delta time ratio limits placed on the
time interpolation associated with the array of streams. this real
value causes the model to stop if the ratio of the running maximum
delta time divided by the minimum delta time is greater than the
dtlimit for that stream. for instance, with daily data, the delta
time should be exactly one day throughout the dataset and the computed
maximum divided by minimum delta time should always be 1.0. for
monthly data, the delta time should be between 28 and 31 days and the
maximum ratio should be about 1.1. the running value of the delta
time is computed as data is read and any wraparound or cycling is also
included. this input helps trap missing data or errors in cycling.
to turn off trapping, set the value to 1.0e30 or something similar.
</desc>

The error you got was:

(shr_strdata_advance) ERROR: for stream 1
(shr_strdata_advance) ERROR: dt limit1 62.0000000000000
28.0000000000000 1.50000000000000
(shr_strdata_advance) ERROR: dt limit2 18500201 0 18500301 0

And the corresponding code is:

SDAT%dtmin(n) = min(SDAT%dtmin(n),dtime)
SDAT%dtmax(n) = max(SDAT%dtmax(n),dtime)
if ((SDAT%dtmax(n)/SDAT%dtmin(n)) > SDAT%dtlimit(n)) then
write(logunit,*) trim(subname),' ERROR: for stream ',n
write(logunit,*) trim(subName),' ERROR: dt limit1 ',SDAT%dtmax(n),SDAT%dtmin(n),SDAT%dtlimit(n)
write(logunit,*) trim(subName),' ERROR: dt limit2 ',SDAT%ymdLB(n),SDAT%todLB(n), &
SDAT%ymdUB(n),SDAT%todUB(n)
call shr_sys_abort(trim(subName)//' ERROR dt limit for stream')
endif

So, 62/28 = 2.2 which is > 1.5

My suggestion was to set dtlimit to something large to avoid this, but looking at this closer this would seem to indicate that you may have a 62 day gap in your forcing data somewhere? I'd look at the time stamps in your forcing files. Maybe your monthly time stamps should be in the middle of the month?

Dear Keith,
Thank you so much for your explanation.

I have looked at the forcing files (using ncdump -v time xxxx.nc) and as we know already it is showing one value for each month (two bnds with days since 0500-01-01):

netcdf \0500-01 {
dimensions:
        time = UNLIMITED ; // (1 currently)
        bnds = 2 ;
        lon = 288 ;
        lat = 192 ;
variables:
        double time(time) ;
                time:standard_name = "time" ;
                time:long_name = "time" ;
                time:bounds = "time_bnds" ;
                time:units = "days since 0500-01-01 00:00:00" ;
                time:calendar = "365_day" ;
                time:axis = "T" ;
        double time_bnds(time, bnds) ;

and by visualizing the NC files (ncview) we see that indeed as you mentioned it is referring to the mid point of each month (see below):




Is this concerning (I mean technically)? ((I have to emphasize that the concern regarding having only one value for month in our specific project is resolved scientifically and we can justify it as well))

Besides that, may I know your helpful opinion on the other forcings I asked in my previous message please (CO2, lnd, etc). Thanks a lot.