restart date specifications

[ezaron]

Hello:

I am having trouble understanding the date specifications used to control the code, and I wonder if you can help.

My desired use-case:
I would like to run the model to spin up for, say, 30 days, with infrequent output specified in the diag_table. Then, I would like to restart for a short period, say, 3 days, and turn on hourly output with diag_table.

I am having trouble getting the model to restart correctly. The model seems to add my run duration, 3 days, to the date inside ocean_solo.res, and it computes an invalid date (February 31) and it won't start. The error message is:
FATAL from PE 0: diag_time_inc: Invalid_date. Date=0001-02-31 00:10:00

I wonder if someone could post or point me to an example of diag_input, input.nml, and MOM_input which is known to work correctly for a use case like this.

Things I am unsure about: Do I need to advance the init_date in input.nml? Do I need to change the date specification on line 2 of diag_table? Do I need to advance the TIDE_REF_DATE to compute tides correctly in the restarted run?

-Ed

 

[marshallward]

I'm not sure about why this isn't working (which is why I haven't replied), but I do not think that you need to edit either `init_date` or the timestamp in `diag_table`. The first is used as a reference time, and AFAIK the date in `diag_table` is more of a label which is passed to other tools.

Did you run 30 days after Jan 1, then another 3 days? Or multiple 3 days intervals, which eventually ran into Feb 31?

 

[ezaron]

Thanks a lot, Marshall.

To answer your question:
The init_date in input.nml was set to "0,0,0,0,0,0", and the calendar was set to "gregorian". The model ran for 30 days.
Then, I tried to restart for 3 more days, and the model complained about the invalid Feb 31 date and failed to run.

Presently, I have a workaround where I run for 27 days, and then I do the restarted run for 3 days, and that appears to work fine.

I will try to set up a test using one of the stock MOM-examples cases so you can reproduce this (or not). Previously, I ran the code and restarted it for a range of arbitrary "real" dates, e.g., "1982,1,1,0,0,0", but in this case I changed to the "0,0,0,0,0,0" start date.

With init_date of "0,0,0,0,0,0", I noticed that the energy diagnostics are output beginning at "MOM Date 1/01/01 00:00:00". Because 0/0/0 does not equal 1/01/01, I think there are date/time gymnastics in the code that I need to look into in detail. This could easily an edge case in the date/time library.

I will raise this issue again when I have a good test case for you (likely in December or January).

-Ed

 

[marshallward]

I wonder if this happens in non-gregorian calendars like noleap. It seems like a very strange bug. What version of FMS are you using?

Good that you at least figured out something that works. If you do manage to get a test case together, my guess is that this would just be passed on to the FMS team.

 

[ezaron]

I'm using the version of FMS -> FMS1 that is pulled in by MOM6-examples:

git status says this:

HEAD detached at f61416fe

The latest entry in git log says this:

commit f61416fef691d9ba39a40df1ce72aa574f54c390
Merge: 83a8dcb2 4eab9e65
Author: colingladueNOAA <60889854+colingladueNOAA@users.noreply.github.com>
Date: Fri Jul 17 16:37:38 2020 -0400