high resolution (0.1 degree) CLM5-BGC-crop regional simulation

[slevis]

I don't know. I usually open files using "vi" and edit them.

 

[xgao304]

I am wondering which file contains "dtlimit" for me to change?

 

[oleson]

dtlimit appears in your datm.streams.xml file. So you would need to change it using your user_nl_datm_streams file in your case directory.

 

[xgao304]

@oleson,

For that error message, should I change "dtlimit" and "ndep_taxmode"?

"ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: for stream 1

Thanks a lot.

 

[oleson]

Actually, I'm not sure why you suspect that the error is due to ndep. The error message is for stream 1 which is usually one of the atmospheric forcing streams.

 

[xgao304]

only because I found a thread which discussed the same error message.

ERROR: (shr_strdata_advance) ERROR dt limit for stream

Thanks,

 

[oleson]

Ok, but I don't see any mention of ndep in that thread. Based on your error message I think I would just change dtlimit as @slevis suggested. If that doesn't work please attach all of your log files and your datm_in and datm.streams.xml file. And it would also be helpful to have the output of an ncdump -v time on one forcing file from each of your datm streams.

 

[xgao304]

@oleson:

I changed dtlimit = 0.125, but still get the similar error message. The attached are the relevant files. I couldn't find "datm.streams.xml", instead I attached all
datm.streams.txt.*. If you need more files, please let me know. Thanks.

 

[oleson]

Ok thanks. Sorry, I thought you were using the new version of the model which has different streams definition files. I think you are using release-cesm2.1.3? It would also be helpful if you could do an ncdump -v time on these two files, which is where I think the error is occurring:

/net/fs04/d2/xgao/CREWSnet/forcing/MRCM-ERA5_grid/Solar/clmforc.MRCM-ERA5.Solr.2012-12.nc

/net/fs04/d2/xgao/CREWSnet/forcing/MRCM-ERA5_grid/Solar/clmforc.MRCM-ERA5.Solr.1983-01.nc

We'll take a look at this tomorrow.

 

[xgao304]

@oleson:

Thanks. Yes, I am using cesm2.1.3.

The attached are two additional files. Thanks a lot for your help.

 

[oleson]

I would check the time stamps on your forcing files. For example, on your precip file I see this for the last few time stamps:

728289, 728292, 728295, 728298, 728301, 736320

It looks like it increments by 3 hours each step until the last one where it increments by 19 hours.
I didn't see any problems with your solar files but I didn't look very closely and there may be a similar problem with those file or the other files.
I would also go back to using the default dtlimit (1.5) since this appears to be 3-hourly data.

 

[xgao304]

@oleson,

Thanks for the suggestion. I corrected the time stamp issue and also use 1.5 for dtlimit, but still get the similar error message.
The attached are relevant files. Could you check them again? Thanks.

 

[oleson]

According to the atm log it looks like it is reading the forcing files correctly at the model's first time step but then is not reading the data again until the point at which you get the dtlimit error, 21 days later. Which still seems to point to a possible problem with the time stamps on the forcing files. It looks like your last forcing file is 2011-12, not 2012-12 as you used last time. Can you send an ncdump -v time for the 2011-12 solar forcing file? I wonder if there is a problem with the time stamp in that file...

 

[xgao304]

I checked and time stamps look fine (see the attachment). yes, I changed the last forcing file to 2011-12 since I found out 2012 has incomplete forcing dara.

Thanks,

 

[oleson]

Well, for now then, I guess I'm out of ideas, sorry.

 

[oleson]

There is a discrepancy between the attribute "actual_range" for the time variable, which is 973011., 973752., but the actual range in the time data is 981027, 981768. In the solar 2011-12 file for example. I wonder if that is somehow a problem. I'm not used to seeing that attribute in forcing files but I don't know if the datm actually uses that at all.

 

[xgao304]

Should I simply remove that attribute? I can give it a try. Also, do i need to change "dtlimit" for testing? Thanks.

 

[oleson]

Probably easiest just to remove it. I would leave dtlimit=1.5

 

[xgao304]

@oleson:

I removed the attribute, but still get the same error message. Is there anything else I could try? Do you think it is worth for me to send you one year of the forcing data and the surface dataset/domain file so that you could test? It is over a small region (Bangladesh), so the files should not be so big. Thanks

 

[xgao304]

@oleson:

Also, based on the log file, does it mean that forcing on 19830121 has the issue? I checked the solar data on 1983/01/21, but could not identify any issue.

Thanks,