Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

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

oleson

Keith Oleson
CSEG and Liaisons
Staff member
I also wonder if it's having trouble parsing the time@units attribute. Your 1983-01 solar file has "hours since 1900-1-1 00:00:00", while your 2011-12 file has "hours since 1900-1-1 00:00:0.0", which are different in terms of how seconds are specified.
GSWP3 forcing has "days since 1901-01-01 00:00:00", which is similar to your 1983-01 file except that "01-01" is "1-1" in your file. The datm should be able to interpret hours since or days since. But you could try formatting your units to the GSWP3 format, including changing the "0.0" to "00".
I'm just guessing at this point though.
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
shr_string_parseCFtunit has this comment:

! Input string is like "days since 0001-06-15 15:20:45.5 -6:00"
! - recognizes "days", "hours", "minutes", "seconds"
! - must have at least yyyy-mm-dd, hh:mm:ss.s is optional
! - expects a "since" in the string
! - ignores time zone part

So maybe the decimal seconds are ok, but it seems to expect mm-dd.
 

xgao304

Member
I changed the time format, but still get the same error message. Any other ideas to test? Thanks,
 

Attachments

  • atm.log.177546.240126-155810.txt
    60.3 KB · Views: 1
  • cesm.log.177546.240126-155810.txt
    178.5 KB · Views: 0
  • cpl.log.177546.240126-155810.txt
    58.7 KB · Views: 0
  • lnd.log.177546.240126-155810.txt
    250.8 KB · Views: 0
  • Solr_198301_time.txt
    4.4 KB · Views: 1
  • Solr_201112_time.txt
    4.4 KB · Views: 0

xgao304

Member
Dear @oleson:

I reprocessed the forcing data (the original forcing data come from someone else), and now I have a different error message. I was looking at the cesm log file and am not very certain about what the problem is. It seems to indicate that some NaN values in the atmospheric fields. I was looking at all the forcing variables at the first time step (241) when the problem occurs, but could not find any NaN value. Could you take a look at the attached log files? Please let me know if you need any other files. The issue is definitely associated with the forcing (just not sure what the problem is) since I can run the model with different forcing at 0.5 degree (not the default cesm forcing) and the same surface and domain data over the same region. Thanks a lot.
 

Attachments

  • atm.log.177784.240129-005315.txt
    12.6 KB · Views: 2
  • cesm.log.177784.240129-005315.txt
    111.3 KB · Views: 2
  • cpl.log.177784.240129-005315.txt
    41.5 KB · Views: 2

slevis

Moderator
@xgao304 I see the error about Sa_dens = NaN in your cpl.log and cesm.log. The short answer is that, unfortunately, troubleshooting things like this is up to the user and not us, because you are using an unsupported model setup.

A longer answer might be to suggest that you think about and look for differences between the non-default DATM dataset that worked and the one that does not, as well as their corresponding simulation cases and their settings. This will be difficult detective work, but that's how it goes in numerical modeling more often than not. And when you solve it, you are a more experienced modeler.
 

xgao304

Member
I am using the exactly model setup for the cases that work and don't work, with the only difference being the forcing.
I am just wondering what the forcing problem is and when (time stamp) that problem occurs based on the log file.
I am not very experienced at deciphering the problems that log files could tell, so would like to seek some professional
advice from you. Thanks.
 

slevis

Moderator
The way to gain experience is to think about the problem and to troubleshoot it yourself. Unfortunately our jobs do not permit the time to solve other scientists issues if they are using unsupported data or code. Sometimes we try anyway as you have already experienced, especially when we can give quick guidance. In this case the error message may give you some guidance where to start, but beyond that you are on your own or with the help of colleagues in your group. I'm sorry.
 
Top