Add capability for relatively arbitrary CICE restart output times

[apcraig]

There is a need by several groups to set relative arbitrary restart output times (ie. hour 3 and hour 24 only). Several groups have implemented something that works for them. We should discuss the best way to add this feature generally. It should be robust, flexible, and clear (if possible). Should we provide/extend a namelist to support a list of times (what format), step numbers, etc? Or should we add a feature that does something like allow a start time, frequency, and end time? Any other ideas? @phil-blain @daveh150 @dabail10 @rallard77

[phil-blain]

Just to start off the discussion, here is what our implementation looks like:

• we set dumpfreq='L', for "list"
• we have an additional dumplist_step array as additional namelist option, arbitrarily hard-coded to size 10
• if the current time step (istep) corresponds to the "current" item in dumplist_step, we write a restart.

[daveh150]

Thank you for starting the discussion Tony! My first thought was similar to the last thing you mentioned, perhaps add dump_start, dump_stop variables. Then the logic in ice_calendar could go like

case (“h”, “H”)

if (elapsed_hours >= dump_start) .and. (elapsed_hours <= dump_stop) then

if (new_hour  .and. mod(elapsed_hours, dumpfreq_n)==0) &

        write_restart = 1

endif

endif

Is that clear? Would that miss any cases?

Thanks, Dave

From: Tony Craig @.> Sent: Thursday, March 9, 2023 17:50 To: CICE-Consortium/CICE @.> Cc: David Hebert, Code 7322 @.>; Mention @.> Subject: [CICE-Consortium/CICE] Add capability for relatively arbitrary CICE restart output times (Issue #819)

There is a need by several groups to set relative arbitrary restart output times (ie. hour 3 and hour 24 only). Several groups have implemented something that works for them. We should discuss the best way to add this feature generally. It should be robust, flexible, and clear (if possible). Should we provide/extend a namelist to support a list of times (what format), step numbers, etc? Or should we add a feature that does something like allow a start time, frequency, and end time? Any other ideas? @phil-blain https://github.com/phil-blain @daveh150 https://github.com/daveh150 @dabail10 https://github.com/dabail10 @rallard77 https://github.com/rallard77

— Reply to this email directly, https://github.com/CICE-Consortium/CICE/issues/819 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AE52VPB7LMZBZ2G4RCWF2GDW3JUCTANCNFSM6AAAAAAVVYGA6M unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[daveh150]

This is how we have it implemented now, we added a dumpfreq = ‘3’…

  case ("3")

     if (istep == nint(( 3.d0*secday/24.d0)/dt) ) &

          write_restart = 1  ! 3 hours into the run

     if (istep == 2*npt12hr)  &

          write_restart = 1  !24 hours into the run

where npt12hr = nint(secday/dt)/2

From: Philippe Blain @.> Sent: Friday, March 10, 2023 08:26 To: CICE-Consortium/CICE @.> Cc: David Hebert, Code 7322 @.>; Mention @.> Subject: Re: [CICE-Consortium/CICE] Add capability for relatively arbitrary CICE restart output times (Issue #819)

Just to start off the discussion, here is what our implementation looks like:

• we set dumpfreq='L', for "list"
• we have an additional dumplist_step array as additional namelist option, arbitrarily hard-coded to size 10
• if the current time step (istep) corresponds to the "current" item in dumplist_step, we write a restart.

— Reply to this email directly, view it on GitHub https://github.com/CICE-Consortium/CICE/issues/819#issuecomment-1463879630 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AE52VPEXKXANJLIG55RCSELW3M2YJANCNFSM6AAAAAAVVYGA6M . You are receiving this because you were mentioned.Message ID: @.***>

[apcraig]

Thanks for the input. There are challenges with all the options above. The start/stop+freq does not cover everything. Lets say you want output at hour 3, 24 and 72. The list option makes sense to me, but the question is what should the units be? Timestep (istep) is easy to implement but more difficult to use. Maybe some sort of date/time format, but that needs to change with each run. Maybe time since the start of this run like 3, 24, and 72 hours? What if you want a restart monthly plus at hour 24 and 48 of the run? Thoughts?

Finally, just to clarify, we are just talking about this feature for restart files? You could also imagine this might be used for instantaneous history files too, but I think we should take that off the table for now.

[apcraig]

Have looked at the code a bit. What I propose is to make dumpfreq, dumpfreq_n, and dumpfreq_base all arrays of size 5. That way, users could set things to write monthly restarts plus restarts every 5 hours plus restarts every 10 timesteps and so forth. A restart would be written for each "frequency". The other thing I propose is to create some new dumpfreq options that basically indicate to do it only once. dumpfreq current allows [y,m,d,h,1]. I would add [y1,m1,d1,h1,11] to indicate write at this frequency once then stop the frequency. So in practice, that might looks like

dumpfreq = 'm','h1','h1' dumpfreq_n = 1,3,24 dumpfreq_base='zero','init','init'

so a restart would be written at the start of each month and just at 3 hours and 24 hours after the run starts.

Does this seem like a flexible enough solution? It also is consistent with how we define multiple history streams, except for the "just once" option which would be just for restarts. Is "y1" a reasonable syntax. Could also do "y_1" or "yonce" or "y_once" or "yfirst" or something else like that to indicate, do it just once.

[apcraig]

See proposed implementation #850.