moddatetime: add starthour and rtimee to support a proper datetime handling#248
moddatetime: add starthour and rtimee to support a proper datetime handling#248adoyenne wants to merge 1 commit into
Conversation
Are you sure? At the end of readinitfiles in modstartup, variable
|
Yes, I checked that. In initdatetime, rtimee is always 0, regardless of whether it’s a cold or warm start. This means that if input data rely on datetime, they will always be read for the cold time, not the warm start time. Currently, the only workaround is to manually adjust the datetime in namoptions to match the warm start time, which is inconvenient. |
Oh, I see, in
I would be a solution, but before the array |
|
One thing I'm hesitant about is that there is already xday and xtime in the DOMAIN namelist, also for setting the starting time. This feels like a duplication. |
well, the reason I added starthour is that xtime should always reflect the cold start time. However, in initdatetime, rtimee is always 0 (it is read from restarts after the call to initdatetime), even for a warm start. Thus, starthour is needed to read emissions correctly for warm starts, accounting for the warm start time. If there were a way to put a correct rtimee to initdatetime (instead of it always being 0), we could likely skip adding starthour. Without this, we cannot read the emissions at the correct times for warm starts.. |
|
After looking a bit more, I like the date handler. Would it be possible to fix this by changing the initialization order, so that the date dandler would know the current rtimee at a restart? I'd rather do that than add a namelist option. |
I tried changing the call positions in startup, but it always resulted in a crash due to dependency/order issues, so it’s not that straightforward. Perhaps you could check whether it’s possible to place the call to initdatetime after reading rtimee from the restart files? |
3 participants
Description:
Update for the moddatetime module to include support for starthour in the namelist and add the rtimee to datetime calculation.
Key changes include:
Added starthour variable to the DATETIME namelist.
Updated datetime initialization to correctly account for starthour when computing the hour and day, including timezone adjustments. rtimee is added to the date calculation.
Added handling notes for rtimee at warmstart. Currently, rtimee is always 0 in this module because it is read from restart files after moddatetime is called (TODO for proper future implementation). When performing a warmstart, the date in the namelist should be set manually to the warmstart time to ensure consistency.
This ensures that simulations starting at non-zero hours are correctly initialized and lays the groundwork for accurate handling of warmstart/restart times.