Outstanding Time Manager Issues

[apcraig]

This is an attempt at aggregating outstanding time manager issues. Several have been fixed as a result of the new JRA55 implementation and the new time manager. But there are still a few outstanding questions/issues.

• We do not read the time axis in the forcing datasets. The file record is based on the yday value and it assumes the input files are yearly and have a particular input frequency. There are few checks that the forcing date and model date actually match. This could be improved (a bunch).
• Still open question about whether we should advance at the beginning of the timestep in the standalone model. The coupled models advance at the beginning, but the standalone advances at the end of the timestep (including at the end of the initialization).
• Some question about the usage of use_restart_time, ice_ic, and runtype interaction. For now, we're leaving as is. Partly this is use_restart_time and runtype = 'continue' #527.
• Documentation/naming of dt and dt_dyn, Timestep documentation and implementation consistency #139.
• Ability to write output at step=1, Small bug in hourly history output #289
• time beg issue, 'time_beg' sometimes not initialized before being written to 'time_bounds' NetCDF variable (NetCDF files not usable by Panoply) #551 , see Fix QC test, fix bug in history time axis, fix history output averaging for timestep output #624
• Problem with hourly output, Hourly output broken by recent time manager update #589, Fix history and restart frequency, new features to scripts #610
• Problem with history time axis. Axis is offset by sec_init when sec_init is not zero. See Fix QC test, fix bug in history time axis, fix history output averaging for timestep output #624.

Feel free to edit (add/remove items) this list here while also commenting below.

[phil-blain]

We could add:

• Remove istep0 from the namelist (and maybe from the code), Update Time Manager #566 (comment)

edited by tcraig on Aug 10, 2021. See below, but I think there may be reasons we want to keep istep0.

[phil-blain]

 Still open question about whether we should advance at the beginning of the timestep in the standalone model. The coupled models advance at the beginning, but the standalone advances at the end of the timestep (including at the end of the initialization).

Tangentially related: this leads to the initial condition being written after the first time step...

Another minor thing I noticed: when using hist_avg = .true., the initial condition is also written as being "averaged" from "time = 0" to "time = after the first time step", which is kind of weird...

[apcraig]

A couple comments. I don't think we should remove istep0. I see a use case where someone runs 100 years and then wants to start a new run from the restart at year 50 and run 50 years with a parameter change. It could be helpful to set istep0 to a value that allows direct comparison of the step numbers of the two runs.

The initial condition is written before the model state is advanced in standalone mode. The problem is that the timestep is advanced as the model is initialized. So the real problem is that the initial condition filename/date is incorrect even though the data is the initial data. I don't think there is a clean way around this. We do not want to subtract a timestep from the date/filename internally as that could create problems for models that don't advance their timestep at initialization. Ultimately, this comes back to the sequencing of time advancement in the model relative to other operations.

I am doing some testing/updates and I have confirmed that history files are written at step=1 with the updated time manager, so have checked that off the list above.