Check CICE4 dump date during setup

[blimlim]

In ESM1.5, the CICE4 restart date settings can be incompatible with the run-length specified in the config.yaml. For example, CICE can be configured to write restarts at yearly intervals, while the run-length could be set one month. In this case, no restart will be written at the end of the run.

In this situation, CICE would previously pick up the wrong restart in subsequent runs. This is addressed by #539, which causes payu to raise an error during setup when the restart file contains the wrong date. This requires two runs before the user is informed that something is wrong with their configuration.

Ideally, we would inform the user at the very start of the first simulation that their run will not produce a valid restart, by comparing the dump settings (dumpfreq, dumpfreq_n) with the run-length.

To implement this, we'll need to properly understand how the dump dates are set within CICE4 in ESM1.5. Based on the code in ice_calendar.F90, it appears that CICE will write restarts when it crosses the boundary of a month or year, instead of using dumpfreq directly as a duration. E.g. the following shows the restarts produced by running 6 month-long runs with dumpfreq=m, followed by a year length simulation with dumpfreq=y:

restart000/ice:
iced.01010201 ...

restart001/ice:
iced.01010301 ...

restart002/ice:
iced.01010401 ...

restart003/ice:
iced.01010501 ...

restart004/ice:
iced.01010601 ... 

restart005/ice:
iced.01010701  ...

restart006/ice:
iced.01020101 

[blimlim]

I've looked more into how CICE in ESM1.5 decides when to write a restart, and will note what I found here.

The calender() subroutine controls which time steps will write restarts, and is called after each ice step. This restart control is done as follows:

First calendar() works out the current date based on how many seconds have passed in the simulation, ttime (see here):

#ifdef AusCOM
      call get_idate(ttime, newh, newd, newm, newy)

Following the logic in the get_idate() subroutine, it will set newy, newm, newd, newh to the year, month, day of year, and hour of day respectively at the current time.

With these values, CICE calculates the current year of the simulation:

      nyr = newy - year_init + 1

E.g. in the first year of a simulation, nyr will equal 1.

The number of elapsed months, days and hours are then calculated:

      elapsed_months = (nyr - 1)*12 + month - 1
      ...
      elapsed_days = int(yday) - 1
      elapsed_hours = int(ttime/3600)

The elapsed_months calculation isn't always correct. If a simulation starts halfway through a year on 0101-07-01, then elapsed_months on 0102-01-01 will be calculated as 12 rather than 6.

Next, CICE checks whether the current time step is the start of a new year, month, or day:

      if (nyr   /= nyrp)   new_year = .true.
      if (month /= monthp) new_month = .true.
      if (mday  /= mdayp)  new_day = .true.

And decides whether to write a restart based on the above values:

        select case (dumpfreq)
        case ("y", "Y")
          if (new_year  .and. mod(nyr, dumpfreq_n)==0) &
                write_restart = 1
        case ("m", "M")
          if (new_month .and. mod(elapsed_months,dumpfreq_n)==0) &
                write_restart=1
        case ("d", "D")
          if (new_day   .and. mod(elapsed_days, dumpfreq_n)==0) &
                write_restart = 1
        end select

There are a few quirks:

• If dumpfreq=y, CICE will write a restart at the boundary between calendar years, rather than after one year of simulation. See the example in the previous comment. Similar is true for dumpfreq=m and dumpfreq=d.

• Since elapsed_months can be incorrectly calculated, restarts may be written at inconsistent gaps. E.g. I started a 12 month simulation on 0101-08-01 with dumpfreq=m, dumpfreq_n=3, and got the following restarts

  iced.01011001  iced.01020101  iced.01020401  iced.01020701 ...
  

  Note the inconsistent spacing.

• nyr used in the dumpfreq=y case is the current year of simulation, and not the number of elapsed years. E.g. in the second year of simulation, nyr=2. This can also lead to restart dates that may be unexpected. E.g. Running a four year simulation starting on 0101-01-01, with dumpfreq=y, dumpfreq_n=2, I got the following restarts:

   iced.01020101  iced.01040101
  

[anton-seaice]

The elapsed_months calculation isn't always correct. If a simulation starts halfway through a year on 0101-07-01, then elapsed_months on 0102-01-01 will be calculated as 12 rather than 6.

I don't follow this bit ?

There is no month_init or day_init so can't simulations only start at the beginning of the year ?

[blimlim]

Good question. A simulation can start on any day of the year, and CICE uses the iniday, inimonth, and iniyear variables to calculate the current date in the get_idate subroutine.

These come from inidate in the ice_in.nml namelist, while the other init_date variable used in other parts of calendar comes from the cice_in.nml namelist.

[anton-seaice]

Oh I see.

What about if we force dumpfreq_n to be 1 ?

I guess I don't want to spend too much time on this because hopefully it will be superseded by CICE5 in ESM1.6 !

[blimlim]

That could work! Just not 100% sure if there are cases where people do want to modify it or not (I suspect probably not?)

Other option I was thinking would be to add a dump_last option to CICE4, so that a restart is always written at the end of the run, similar to how it's handled in OM2. I think this would avoid having to check any restart dates during setup in payu, and might also be a bit more user friendly. E.g. you could change the run length without having to worry about the dumpfreq setting.

I've got two trials of this here and here – the changes are fairly straightforward. When doing monthly runs with dump_last=.true. and dumpfreq=y, both produce identical restarts at the end of each month as the default exe using dumpfreq=m.