spinup question:

[Evgeny_Chur]

Dear all,

I'm quite confused. I want to run a spinup simulation with my forcing data from previous B1850 simulation:

I'm using this settings:

# -- Simulations domain
gridname=fv0.9x1.25_gx1v7.151020

export CTSM_ROOT=/work/mj0143/b381275/CTSM
# Model components (COMPSET):
export COMPSET=I1850Clm50BgcCrop
export CLM_USRDAT=f09_g17
export CASENAME=$case
export DIR_CASE=/home/b/b381275/CTSM_runs/$CASENAME

# Step 1: Create case
if ! [ -d $DIR_CASE ]; then
cd $CTSM_ROOT/cime/scripts
./create_newcase --case $DIR_CASE --compset $COMPSET --res $CLM_USRDAT --mach levante --run-unsupported --driver mct
fi

cd $DIR_CASE
# Additional settings:
./xmlchange CLM_ACCELERATED_SPINUP="on"
./xmlchange CLM_FORCE_COLDSTART="on" # Add 18.08.2023

# Information about grid for forcing:
./xmlchange ATM_DOMAIN_FILE=domain.lnd.$gridname.nc
./xmlchange LND_DOMAIN_FILE=domain.lnd.$gridname.nc
./xmlchange CLM_USRDAT_NAME=$gridname
./xmlchange CLM_USRDAT_DIR=/work/mj0143/b381275/inputdata/share/domains

# Settings for model run:
./xmlchange RESUBMIT=10,STOP_N=3,STOP_OPTION=nyears,RUN_STARTDATE=0001-01-01,DATM_CLMNCEP_YR_START=1850,DATM_CLMNCEP_YR_END=1880

# env_build.xml changes
./xmlchange MOSART_MODE=NULL # Turn off MOSART model
#./xmlchange MOSART_IGNORE_WARNINGS=TRUE # Turn on MOSART warnings

# -- Set a new case:
./case.setup

# Users namelists: 18.08. changed to opt5
cp /work/mj0143/b381275/CTSM_forcing/myforcing/opt5/user_nl_clm .
cp /work/mj0143/b381275/CTSM_forcing/myforcing/opt5/user_nl_datm .

# -- FORCING (data from Sebastian):
cp /work/mj0143/b381275/CTSM_forcing/myforcing/opt5/user_datm.streams.txt.CLMGSWP3v1.Solar .
cp /work/mj0143/b381275/CTSM_forcing/myforcing/opt5/user_datm.streams.txt.CLMGSWP3v1.Precip .
cp /work/mj0143/b381275/CTSM_forcing/myforcing/opt5/user_datm.streams.txt.CLMGSWP3v1.TPQW .

also in my user_nl_clm and user_datm_in namelists have:

# USER_NL_CLM
use_init_interp = .true.
reset_snow = .true.
hist_fincl2 = 'TG','TBOT','FIRE','FIRA','FLDS','FSDS',
'FGEV','TSOI','TSA','FCTR','FCEV','QBOT','RH2M','H2OSOI',
'H2OSNO','GPP', 'NPP', 'NEE', 'LWdown','Qle','AnnET'
hist_nhtfrq = 0, 0
hist_mfilt = 1, 12

finidat='/work/mj0143/b381275/inputdata/lnd/clm2/initdata_map/clmi.I1850Clm50BgcCrop-ciso.1366-01-01.0.9x1.25_gx1v7_simyr1850_c200428.nc'

# USER_DATM_IN
streams = "datm.streams.txt.CLMGSWP3v1.Solar 1850 1850 1880",
"datm.streams.txt.CLMGSWP3v1.Precip 1850 1850 1880",
"datm.streams.txt.CLMGSWP3v1.TPQW 1850 1850 1880"
dtlimit = 1e30, 1e30, 1e30, 1e30, 1e30

and when I'm trying to run this script, I got these ERROR:

WARNING: CLM is starting up from a cold state
ERROR: Command /work/mj0143/b381275/ctsm_levante/bld/build-namelist failed rc=255
out=
err=Warning : CLM build-namelist::CLMBuildNamelist::setup_logic_initial_conditions() : setting finidat (either explicitly in your user_nl_clm or by doing a hybrid or branch RUN_TYPE)
is incomptable with using a cold start (by setting CLM_FORCE_COLDSTART=on).
-- Add -ignore_warnings option to CLM_BLDNML_OPTS to ignore this warning

1) If I don't set these parameters (use_init_interp and finitdat ) in user_nl_clm model works fine. However, I'm not sure is it OK or not ? and What will happened if I add ignore_warnings option to CLM_BLDNML_OPTS?

2) If I use ./xmlchange CLM_FORCE_COLDSTART="off" and ./xmlchange CLM_ACCELERATED_SPINUP="on" and the same namelits, I got spinup results which starts not from zero and I have no idee why it can happened. I attached 3 files from this simulation (settings.txt, datm_in and lnd_in). Can you clarify, maybe what should I checked in my settings?

3) I use daily forcing from previous B1850 simulation and I didn't change parameters from run_coupling group. These parameters are equal to LND_NCPL: 48, ATM_NCPL: 48 , NCPL_BASE_PERIOD: day. Should I change them, if I use daily forcing or can I use the default values?

<?xml version="1.0"?>
<file id="stream" version="1.0">
<dataSource>
GENERIC
</dataSource>
<domainInfo>
<variableNames>
time time
xc lon
yc lat
area area
mask mask
</variableNames>
<filePath>
/work/mj0143/b381275/inputdata/atm/datm7/atm_forcing.datm7.MODEL/FORCING
</filePath>
<fileNames>
domain.lnd.fv0.9x1.25_gx1v7.151020.nc
</fileNames>
</domainInfo>
<fieldInfo>
<variableNames>
PSL pbot
QREFHT rh
TREFHT tbot
FLDS lwdn
WIND wind
</variableNames>
<filePath>
/work/mj0143/b381275/inputdata/atm/datm7/atm_forcing.datm7.MODEL/FORCING/TPHW
</filePath>
<fileNames>
TPHW_1850.nc
TPHW_1851.nc
TPHW_1852.nc
TPHW_1853.nc
TPHW_1854.nc
TPHW_1855.nc
TPHW_1856.nc
TPHW_1857.nc
TPHW_1858.nc
TPHW_1859.nc
TPHW_1860.nc
TPHW_1861.nc
TPHW_1862.nc
TPHW_1863.nc
TPHW_1864.nc
TPHW_1865.nc
TPHW_1866.nc
TPHW_1867.nc
TPHW_1868.nc
TPHW_1869.nc
TPHW_1870.nc
TPHW_1871.nc
TPHW_1872.nc
TPHW_1873.nc
TPHW_1874.nc
TPHW_1875.nc
TPHW_1876.nc
TPHW_1877.nc
TPHW_1878.nc
TPHW_1879.nc
TPHW_1880.nc
</fileNames>
<offset>
0
</offset>
</fieldInfo>
</file>

Best regards,
Evgenii

 

[slevis]

This is a lot, so I hope I didn't miss something. I will try to answer (1) and (2).

You wrote that you want a new spinup simulation with forcing data from a previous B1850 simulation. If so, then (1) is correct because a new spinup does not use existing initial conditions to start. So do not set use_init_interp and finidat in user_nl_clm and keep CLM_FORCE_COLDSTART=on.

Option (2) uses initial conditions found in finidat, which explains why the simulation does not start from zero.

I don't know the answer to (3).

 

[Evgeny_Chur]

This is a lot, so I hope I didn't miss something. I will try to answer (1) and (2).

You wrote that you want a new spinup simulation with forcing data from a previous B1850 simulation. If so, then (1) is correct because a new spinup does not use existing initial conditions to start. So do not set use_init_interp and finidat in user_nl_clm and keep CLM_FORCE_COLDSTART=on.

Option (2) uses initial conditions found in finidat, which explains why the simulation does not start from zero.

I don't know the answer to (3).

Dear Sam,

Thank you for your answer and these clarifications.

I have adapted the running script and run the new test spinup simulation (only 30 years) with active CLM_FORCE_COLDSTART parameter. I got results. It looks better that it was before and the new spinup simulation starts from zero.

However, I would like to clarify one extra moment.

In github documentation, I found examples of different spinup simulations (1.5.5. Spinup of CLM5.0-BGC-Crop — ctsm release-clm5.0 documentation) and the output results generated by SpinupStability.ncl script. I have adapted this script for my case and got the figures (attached). However, the values in variable Land Area in TOTECOSYSC parameter looks strange.

My question:
Can you clarify, what do you think about my values of Land Area in TOTECOSYSC parameter (fine or strange and the first values should be not more than 40 - 50%)? Is fsurdat parameter is responsible for that or should I set extra land/sea mask?


Best regards,
Evgeniii

 

[oleson]

It looks like from your files that you are looping over years 1850 through 1880 for your spinup which is 31 years. You would set "subper" in the spinup script to 31. You'd then need at least 62 years of simulation for the script to work properly as it samples the data every "subper" years to assess equilbrium. You might consider looping over a more limited set of years, e.g., 10, if they are all "1850" years anyway.
Also, I don't think using daily average data to spinup is going to work well as you won't get a diurnal cycle in most variables. Typically, we will generate "CPLHIST" files from a fully coupled run that contain data at a sub-daily time step and then use that to drive CLM.

 

[Evgeny_Chur]

It looks like from your files that you are looping over years 1850 through 1880 for your spinup which is 31 years. You would set "subper" in the spinup script to 31. You'd then need at least 62 years of simulation for the script to work properly as it samples the data every "subper" years to assess equilbrium. You might consider looping over a more limited set of years, e.g., 10, if they are all "1850" years anyway.
Also, I don't think using daily average data to spinup is going to work well as you won't get a diurnal cycle in most variables. Typically, we will generate "CPLHIST" files from a fully coupled run that contain data at a sub-daily time step and then use that to drive CLM.

Dear Keith,

Thank you for your answer and important clarification about "subper" parameter. I will try to look at the test simulation with a more limited set of years. Also, I will try to get forcing data with another time step.

Best regards,
Evgenii

 

[Evgeny_Chur]

Dear all,

I have prepared a global SPINUP simulation with my input data from previous B1850 simulation. The original input data has a daily time steps. In case of TOTPREC it was average daily values. Using this forcing, model works fine, but when I compared the amplitude of GPP and NPP parameters with the same spinup prepared by GSWP3 forcing (reference). I found that the reference experiment has GPP values in several times bigger that my results.

Then I compared the amplitude of TOTPREC input parameter (B1850 and GSWP3) and found that I have problems with total precipitation. Later, I used cdo (inttime) and NCO software and created the new input dataset with 3 hourly time steps. Later, I compared the amplitude of input parameters again and got comparable results.
Nevertheless, when I'm trying to run the model with the new dataset (timestep - 3 hour), I got an error:
Note: sink > source in ch4_tran, sources are changing quickly relative to diff
70: usion timestep, and/or diffusion is rapid.
I turned off the metane model use_lch4 = .false.

and got another problem 71: ERROR: ERROR in CNBalanceCheckMod.F90 at line 309

I think that problem is in my forcing, but I checked it several times and everything looks fine. For quality test I used my python script. Can you help me to understand why I cannot run the model with 3 hourly timesteps.


My datm_in file:

&datm_nml
decomp = "1d"
factorfn = "null"
force_prognostic_true = .false.
iradsw = 1
presaero = .true.
restfilm = "undefined"
restfils = "undefined"
wiso_datm = .false.
/
&shr_strdata_nml
datamode = "CLMNCEP"
domainfile = "/work/mj0143/b381275/inputdata/share/domains/domain.lnd.fv0.9x1.25_gx1v7.151020.nc"
dtlimit = 1e30, 1e30, 1e30, 1e30, 1e30
fillalgo = "nn", "nn", "nn", "nn", "nn"
fillmask = "nomask", "nomask", "nomask", "nomask", "nomask"
fillread = "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET"
fillwrite = "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET"
mapalgo = "bilinear", "bilinear", "bilinear", "bilinear", "bilinear"
mapmask = "nomask", "nomask", "nomask", "nomask", "nomask"
mapread = "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET"
mapwrite = "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET", "NOT_SET"
readmode = "single", "single", "single", "single", "single"
streams = "datm.streams.txt.CLMGSWP3v1.Solar 1850 1850 1859",
"datm.streams.txt.CLMGSWP3v1.Precip 1850 1850 1859",
"datm.streams.txt.CLMGSWP3v1.TPQW 1850 1850 1859",
"datm.streams.txt.presaero.clim_1850 1 1850 1850",
"datm.streams.txt.topo.observed 1 1 1"
taxmode = "cycle", "cycle", "cycle", "cycle", "cycle"
tintalgo = "coszen", "nearest", "linear", "linear", "lower"
vectors = "null"
/

Best regards,
Evgenii

 

[slevis]

If you changed the model timestep to 3 hours, then I would change that back to the default (0.5 hours). The model timestep does not need to be the same as the timestep of your new input data.

 

[Evgeny_Chur]

Dear Sam,

Thank you for your reply. It works fine with forcing data from the previous BHIST simulation. Nevertheless, I got another problem if I want to use the results of nudged simulation, started 6 hours later.

I can see that problem is in total sensible heat flux:

54: ERROR: ERROR in UrbanFluxesMod.F90 at line 827
62: WARNING: Total sensible heat does not equal sum of scaled heat fluxes for urba
62: n columns nstep = 0 indexl= 385 eflx_err=
62: -2.219512246948733E+023
62: clm model is stopping - error is greater than .01 W/m**2
62: eflx_scale = -2.473619076746079E+037
62: eflx_sh_grnd_scale: -3.762742815725877E+036 -1.847164639423062E+036
62: -1.847164639423062E+036 -5.759705880991021E+036 -1.151941279189777E+037
62: eflx = -2.473619076746057E+037
62: iam = 62: local landunit index = 385
62: iam = 62: global landunit index = 13235
62: iam = 62: global gridcell index = 6471
62: iam = 62: gridcell longitude = 151.2500000
62: iam = 62: gridcell latitude = -32.5130890
62: iam = 62: landunit type = 9
62: ENDRUN:

but I don't understand how can I fixed it? Can it be related with time axis (time.txt) of my nudge input forcing?

I compared my data with GSWP3 data and amplitude looks comparable.






Best regards,
Evgenii

 

[oleson]

Generally, an error of that magnitude (e23) means that there is probably some forcing data being used that is missing value (e.g., 1e36). That could happen either if there is actually missing forcing data or a mismatch between the datm domain and the CLM surface dataset. I'd suggest printing out the forcing data used within the model.

 

[Evgeny_Chur]

Generally, an error of that magnitude (e23) means that there is probably some forcing data being used that is missing value (e.g., 1e36). That could happen either if there is actually missing forcing data or a mismatch between the datm domain and the CLM surface dataset. I'd suggest printing out the forcing data used within the model.

Dear Keith,

Thank you for your reply and recommendations. I'm not sure how to print out the full list of input files used within the model? because of that I attached my streams and atm and cesm log files.

Best regards,
Evgenii

 

[Evgeny_Chur]

I found a problem. My WIND field has a lot of NaN values.

 

[Houhhu]

Hi @oleson ,sorry for bother you. I meet the similar question about urban incident atmospheric longwave radiation balance error.

urban incident atmospheric longwave radiation balance error
  1.475739525896764E+020
 l          =         6966
 lwdown     =   9.999999616903162E+035
 vf_sr      =   6.911273996795408E-002
 vf_sw      =   6.464495032584287E-002
 canyon_hwr =    7.19999980926514
 clm model is stopping
 local  landunit index =         6966
 global landunit index =       362703
 global gridcell index =       144094
 gridcell longitude    =    129.350000000000
 gridcell latitude     =    35.5500000000000
 landunit type         =            7
 ENDRUN:
 ERROR: ERROR in UrbanRadiationMod.F90 at line 494

Now I have konwn there is some forcing data being used that is missing value (e.g., 1e36). My datm domain lon ranges from 70°E to 140°E, and lat ranges from 15°N to 55°N, including whole china. However, my forcing data is only valid in the China land region and missing vaule( 1e36 ) outside the China land region.The error Position longitude:129.35 latitude:35.55 actually is in South Korea. I dont have a exact value in that position and cause the error.

In order to sovle this problem, I try to change all missing value to the mean value (in the china land region) . I will clip the model output to the China region, because I only care about the China region.

Do you think it is resonable? If I use the mean vaule instead of missing value, will it have an effect on the simulated output of the boundary area ?
Or could you give me advice about this issue?

one of foring data picture is attached behind. the blank region is missing vaule

 

[slevis]

I think your suggestion should work and should have no effect on the simulation over China.

 

[Sijia Chen]

If you changed the model timestep to 3 hours, then I would change that back to the default (0.5 hours). The model timestep does not need to be the same as the timestep of your new input data.

Dear slevis,where i can change the model timestep,at /CaseDoces/lnd_in?

 

[slevis]

I searched for "change timestep" in the Search Forums tab above and found this explanation for the atmosphere, which I hope will work in a similar way for the land:

Changing the timestep in CAM-FV

Dear CAM users, Can I run CAM-FV with resolution of 1.9X2.5 by changing its model timestep from 1800s(default) to 600s? Thank you.

bb.cgd.ucar.edu

 

[Sijia Chen]

我在上面的搜索论坛标签中搜索了 “change timestep” 并找到了这个关于大气层的解释，我希望它也能以类似的方式适用于这张地牌：
[网址 unfurl=“true”]https://bb.cgd.ucar.edu/cesm/threads/changing-the-timestep-in-cam-fv.9281/post-53761[/网址]T

Thank you very much