Problems with custumed atmospheric forcings in clm5.0

[majun]

Dear scinetist,
I have successfully replace the default GSWP3 forcing with my atm forcing (named CMFD, all of the seven forcing variable is with 3hr and 0.1° resolution) in clm5.0 and it works with the following three steps:
(1) Setup my case using GSWP3 forcing and modify files from there
(2) create a new domain file which is matched with atm forcing.
(3) modify the three stream files

However, the simulated dirunal cycle of LST ('TSKIN', 2004 average) of my study region is unreal (with an anomaly in UTC 10.30 am, see attached file1), while forced with GSWP3 is normal. I found it is the problem of FSDS ( solar radiation),see attached file2（model output FSDS). I think it may be caused by the reason that incoming solar radiation is not lined up with the cosine of the solar zenith angle in the model. I checked the origional CMFD solar, and make a comparsion with GSWP3 in 2004-07-28 and 2004-07-31 and found it is reasonable(see attached file3,4). The solar (including FSDS and FLDS) in CMFD is 3-hourly mean (from −1.5hr to +1.5hr) surface downward shortwave(longwave) radiation, while precipitation is 3-hourly mean (from −3.0hr to 0.0hr) precipitation rate.
I see the clm model needs to set the time axis from 00:00 UTC, so I write all of the seven forcing variables from 00:00 UTC and set all the offsets to zero, then an unexpected lst value has occurred in UTC 10:30 as I repoted above.
I see in clm user guide "Example of DATM stream files with your own forcing for 3-hourly data" , the offset of prec is set to -5400, while solar is -10800. So I change the offset value in user_datm.streams.txt.CLMGSWP3v1.Solar to -5400/-10800
However, when ./case.submit, it came wrong and shows :
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream

The datm_in of mine is as follows:
dtlimit = 1.5, 1.5, 1.5, 1.5, 1.5
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 2004 2004 2004",
"datm.streams.txt.CLMGSWP3v1.Precip 2004 2004 2004",
"datm.streams.txt.CLMGSWP3v1.TPQW 2004 2004 2004",
"datm.streams.txt.presaero.clim_2000 1 2000 2000",
"datm.streams.txt.topo.observed 1 1 1"
taxmode = "cycle", "cycle", "cycle", "cycle", "cycle"
tintalgo = "coszen", "nearest", "linear", "linear", "lower"
vectors = "null"

Anyboday know how to fix it out? Any suggestion or help is highly appreciated.

 

[oleson]

The error is pointing to streams 2, which is normally the precipitation stream, not the solar. So maybe the time dimension on your precip file is wrong, or an offset is needed or the offset you are using is wrong. It could be one wrong thing or a combination of things, I can't tell.
If you can't figure it out after reasonable effort, attach or send me:
datm_in
datm.streams.txt.CLMGSWP3v1.Precip
datm.streams.txt.CLMGSWP3v1.Solar
datm.streams.txt.CLMGSWP3v1.TPQW

and the actual atmospheric forcing files you are using (preferably all of year 2004), and the domain file you are using in your streams files, and I will try to see if I can run such a case here.

 

[majun]

The error is pointing to streams 2, which is normally the precipitation stream, not the solar. So maybe the time dimension on your precip file is wrong, or an offset is needed or the offset you are using is wrong. It could be one wrong thing or a combination of things, I can't tell.
If you can't figure it out after reasonable effort, attach or send me:
datm_in
datm.streams.txt.CLMGSWP3v1.Precip
datm.streams.txt.CLMGSWP3v1.Solar
datm.streams.txt.CLMGSWP3v1.TPQW

and the actual atmospheric forcing files you are using (preferably all of year 2004), and the domain file you are using in your streams files, and I will try to see if I can run such a case here.

Thanks a lot, I have sent all of the above files you mentioned to your email.

 

[oleson]

Thanks for the files. I've run for 1 month with two different configurations:
The first is with offsets of +5400 for Precip and TPQW and -10800 for Solar. Your forcing files are all time stamped at the beginning of the 3-hour time period. The Precip and TPQW should be time-stamped at the middle of the 3-hour period (according to the User's Guide), so I used offsets to move those to the middle of the time period (5400s = 1.5hrs) (jbuzan also suggested this in a separate post). The Solar should be time-stamped at the beginning of the time period, which yours is. However, from your plots it looked like the CMFD solar peak was 3 hours later than GSWP3, so I used an offset of -10800 to shift it. The resulting solar from the model run looked better to me, but it still looked like there was some diurnal asymmetry.
So, in the second configuration, I used an offset of -5400, just for the solar. I had to set a dtlimit of 2.0 for solar because I got a dtlimit error at the start of the simulation:
dtlimit = 2.0, 1.5, 1.5, 1.5, 1.5 in user_nl_datm.
The solar resulting from the coszen interpolation looked more symmetrical in this second configuration.
That's probably as much time as I should spend on this. You can take a look at these two configurations in your simulation and decide if the diurnal cycles of solar, longwave, temperature, etc. make sense and are also consistent with the CMFD data. For example, I would expect the forcing temperature to peak in the afternoon, after the solar peak.
Ideally, I think you should configure your time-stamps and your data to be consistent with what is defined in the User's Guide, it's less confusing than using the offsets, and you can encounter dtlimit errors when starting simulations and when cycling over the forcing data.

 

[majun]

Thanks for the files. I've run for 1 month with two different configurations:
The first is with offsets of +5400 for Precip and TPQW and -10800 for Solar. Your forcing files are all time stamped at the beginning of the 3-hour time period. The Precip and TPQW should be time-stamped at the middle of the 3-hour period (according to the User's Guide), so I used offsets to move those to the middle of the time period (5400s = 1.5hrs) (jbuzan also suggested this in a separate post). The Solar should be time-stamped at the beginning of the time period, which yours is. However, from your plots it looked like the CMFD solar peak was 3 hours later than GSWP3, so I used an offset of -10800 to shift it. The resulting solar from the model run looked better to me, but it still looked like there was some diurnal asymmetry.
So, in the second configuration, I used an offset of -5400, just for the solar. I had to set a dtlimit of 2.0 for solar because I got a dtlimit error at the start of the simulation:
dtlimit = 2.0, 1.5, 1.5, 1.5, 1.5 in user_nl_datm.
The solar resulting from the coszen interpolation looked more symmetrical in this second configuration.
That's probably as much time as I should spend on this. You can take a look at these two configurations in your simulation and decide if the diurnal cycles of solar, longwave, temperature, etc. make sense and are also consistent with the CMFD data. For example, I would expect the forcing temperature to peak in the afternoon, after the solar peak.
Ideally, I think you should configure your time-stamps and your data to be consistent with what is defined in the User's Guide, it's less confusing than using the offsets, and you can encounter dtlimit errors when starting simulations and when cycling over the forcing data.

Thanks so much for your kind help, it costs you a lot of time, thanks so much. I will follow your tips to ensure the diurnal cycles of solar, longwave, temperature, etc. make sense and are also consistent with the CMFD data. In addition, I have some questions as follows,
(1) The 3hr Precip neeed in CLM is three hourly mean or three hourly accumulated?
(2) what does dtlimit mean? If I want to set offset to -10800, what value should I set to dtlimit?

 

[oleson]

(1) mean in kg/m2/s
(2) From the data model documentation at 3. Input Streams — CIME master documentation:

"Specifies delta time ratio limits placed on the time interpolation associated with the array of streams. 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.

default=1.5"

The default of 1.5 will work for -10800

 

[majun]

Sorry, I didn't know kg/m2/s means..., I mean the precip in GSWP3 is three hourly mean or three hourly total? I make clear the origional CMFD data's generation (The solar,including FSDS and FLDS, in CMFD is 3-hourly mean (from −1.5hr to +1.5hr) , for example, the FSDS in UTC 03:00 is a mean value from UTC 01:30 to UTC 04:30 ; while precipitation is 3-hourly mean (from −3.0hr to 0.0hr) precipitation rate; The other variables, is an instantaneous value, see attached picture1) . I write all of this time stamped at the beginning of the 3-hour time period to force clm.
To be honest, I'm a little stupid on this. I don't know how to configure my time-stamps and my data to be consistent with what is defined in the User's Guide...(maybe write the 'time' option like in GSWP3 as 'time' field is 0.0625-30.9375 in Precip and TPQW ,whiel 0-30.875 in Solar? )
I did the two different experiments follows your configurations. In Configuration 1 (with offsets of +5400 for Precip and TPQW and -10800 for Solar) , I encounter dtlimit errors ((shr_strdata_advance) ERROR: for stream 2) . In Configuration 2 (I used an offset of -5400, just for the solar and set a dtlimit of 2.0 for solar) , it runs successfully and the output TSKIN and FSDS looks normal compared with GSWP3. However, I found model output's TBOT, QBOT, PBOT. etc forced by CMFD is 1.5hr after than with GSWP3 (take 2004 July average as an example, see attached file2 and 3, the wrong unit can be ignored, however, I'm still not sure about Precip and FLDS offset, it seems odd (do you have any idea?))
Finally, I set all of the three stream files offset to -5400, and change ditlimit to 2.0, 1.5, 1.5, 1.5, 1.5 in user_nl_datm. I found model output's TBOT, QBOT, FSDS,TKSIN is comparable with GSWP3. But precip is still odd，what do you think about my configuration?
I'm so sorry I have bothered you so much, I konw you are busy, but I have nodoby to ask about this... I really want to get it right. Thanks !
Additional questions are summarized below:
(1) Among the seven atm forcings，what are the main influence factors to TSKIN in CLM？ Actually, I just want to ensure the simulated LST is correct.
(2) If I don't use FLDS, does it matters?
(3) I don't know the structure of the seven variables in GSWP3, they are instantaneous value or 0-3hr or -1.5hr-1.5hr or -3hr-0 mean? I'm a little confused.

 

[majun]

Dear oleson,
Thanks for your previous help, begging for your final check .... I set all of the three stream files offset to -5400, and change ditlimit to 2.0, 1.5, 1.5, 1.5, 1.5 in user_nl_datm, and do a whole year experiment(2004) for CMFD and GSWP3, then I output the variables of TSKIN, FLDS, QBOT, TBOT, PBOT and RAIN_FROM_ATM, see the attached file, it seems like model output's TBOT, QBOT, PBOT,TKSIN is comparable with GSWP3. But precip and FLDS are still odd, do you have any suggestions? The study area's local time is UTC+8hr.
Thanks, please...

 

[oleson]

I'm not sure what you find odd about precip. It looks like the mean precip is being repeated for the model time steps for each 3 hour period as it should.
If you don't want to use CMFD FLDS, then exclude it from your stream file. The model will then calculate it based on Idso (1981) as described here:

2.33. Land-Only Mode — ctsm release-clm5.0 documentation

 

[majun]

I'm not sure what you find odd about precip. It looks like the mean precip is being repeated for the model time steps for each 3 hour period as it should.
If you don't want to use CMFD FLDS, then exclude it from your stream file. The model will then calculate it based on Idso (1981) as described here:

2.33. Land-Only Mode — ctsm release-clm5.0 documentation

So do you think my offset on preip(-5400) is right ? I'm not confident about my configuration now... so sad ..

 

[oleson]

I do see now that you said that CMFD precip " is 3-hourly mean (from −3.0hr to 0.0hr) precipitation rate". And you have the first time sample stamped at time zero, which is at the end of the first time period. GSWP3 is time stamped at the middle of a 3-hour period (in accordance with the User's Guide) But you've used the offset to move CMFD back 1.5 hours so that it is effectively now at the middle of the time period (-1.5 hrs), so I think you have done it correctly.
But that is just my opinion, it's obviously up to you to decide.

 

[majun]

I think you have all the information to make a decision yourself, I don't have an opinion at this point.

thanks a lot, it costs you lots of time ,thanks!

 

[oleson]

Just wanted to make sure you saw my last comment above.

 

[majun]

I do see now that you said that CMFD precip " is 3-hourly mean (from −3.0hr to 0.0hr) precipitation rate". And you have the first time sample stamped at time zero, which is at the end of the first time period. GSWP3 is time stamped at the middle of a 3-hour period (in accordance with the User's Guide) But you've used the offset to move CMFD back 1.5 hours so that it is effectively now at the middle of the time period (-1.5 hrs), so I think you have done it correctly.
But that is just my opinion, it's obviously up to you to decide.

I can‘t express my gratitude... thanks

 

[majun]

Dear oleson, a small question, I see that in clm model, solar should be time-stamped at the beginning of the 3-hour period, the solar here is referred to FSDS or both FSDS and FLDS?

 

[oleson]

Just FSDS (incoming solar radiation). FLDS is incoming longwave radiation. In GSWP3, FLDS is included in the stream with TBOT, QBOT, etc.

 

[majun]

Thanks for your help. Forgive me for the serial question... I hope it will be the last question on this topic. Under your help, I think I have solved this problem (i.e. all of the three streams are with -5400 offset) , I output the February average rain from clm model and compare it with origional CMFD data(see attached fig.1). Meanwhile, cause the TBOT, QBOT, PBOT and wind in CMFD is an instantaneous value, I also give it -5400 offset, and compare model output between CMFD and GSWP3 (see attahced fig.2) . I don't use FLDS. I think I'm right , but I'm not confident, what's your opinion ?
What's more，I meet an odd problem when in spinup period (1999-2003). Refer to the above configuration (all of the three streams are with -5400 offset, and files start from 1999-01.nc .....to 2004-01.nc ), I set the follow configuration in env_run.xml:
./xmlchange DATM_CLMNCEP_YR_START=1999
./xmlchange DATM_CLMNCEP_YR_END=2003
./xmlchange STOP_OPTION=nyears
./xmlchange STOP_N=5
./xmlchange RUN_STARTDATE=1999-01-01
./xmlchange STOP_DATE=20031231
It run successfully, however, the output netcdf files' name is from spinup_CMFD.clm2.h0.1993-01.nc.... to spinup_CMFD.clm2.h0.1997-12.nc, what's the problem ???

 

[oleson]

If you have snow in your domain, you should compare the sum of rain and snow to the CMFD precip to see if they agree.
Not sure about your other problem. Maybe your xmlchange for RUN_STARTDATE didn't work (check your env_run.xml), or you are actually doing a restart or branch without realizing it.

 

[majun]

Dear Oleson,
Thanks for your previous help on this topic. As mentioned before (7 months ago, you may forget), I set the offset of CMFD's preip, Solar and TPHWL both to -5400 , then the CMFD-forced LST looks symmetrical, so I regard it as the correct configuration. However, recent days, I compare the CMFD modelling LST (with 0.5hr temporal resolution) with in-situ LST （100°E, 39°N, local time = UTC+8），it looked like the CMFD LST peak was still 1.5 hours later than GSWP3 modelling LST and in-situ LST. So I set the solar offset to -10800 (hereafter named CMFD_-10800), it looks like the LST peak matched, but the coszen interpolation becomes asymmetric（ a small drop at UTC 4:00 and a linear decrease at UTC 7:00）, do you konw what's the problem? thanks a lot !
The comparison results are attached below, fig.1. compares CMFD modelling LST, GSWP3 modelling LST and CLDAS LST( China Land Data Assimilation System LST, 1hr resolution) with in-situ LST; fig.2. compares CMFD modelling LST, CMFD_-10800 modelling LST and CLDAS LST with in-situ LST.
Remind: FSDS in CMFD is 3-hourly mean (from −1.5hr to +1.5hr) , Precip is 3-hourly mean (from −3.0hr to 0.0hr) , where TPHWL is an instantaneous value. I write all the forcing from UTC 00:00 as the first value.

 

[oleson]

I can't help with this anymore sorry. Maybe someone else can help. It's really up to you to investigate problems associated with customized atmospheric forcing and comparison to observations/reanalysis. One thing to keep in in mind though is consistency when comparing forcing (air) temperature and in situ temperature (which could be either air or surface temperature, I don't what CLDAS LST represents).