ESM1.6: Inconsistent `frz_onset` output

[blimlim]

See here for more background.

The frz_onset field records the day of year when ice first forms on a gridcell, either via congel or frazil.

The frz_onset output has a strange dependence on the early steps of the calendar initialisation. In particular, during the init_restart subroutine, there is the following call to the calendar subroutine:

cice5/drivers/access/CICE_InitMod.F90

Lines 364 to 369 in 0bd0131

	if (trim(runtype) == 'continue') then
	! start from core restart file
	call restartfile() ! given by pointer in ice_in
	!ars599: 11042014: markout call calendar
	! according to dhb599 initmod at cice4.1_fm
	call calendar(time) ! update time parameters

From the tests described here, frz_onset takes different values based on whether time is less than or greater than one year (in seconds). These differences only show up in a few points in the southern hemisphere:

It's unclear why this happens, and what the correct behaviour should be. The value of time at this particular calendar call seems like it's arbitrary, as the start time is only properly initialised later:

cice5/drivers/access/CICE_InitMod.F90

Line 193 in 0bd0131

time = runtime0 !............

And the model date is only correctly initialised at this later calendar call which still happens before the model starts running:

cice5/drivers/access/CICE_InitMod.F90

Line 215 in 0bd0131

call calendar(time-runtime0)

---

With the original calendar setup (i.e. from CM2), the time argument will come from an earlier call to init_calendar:

cice5/source/ice_calendar.F90

Line 133 in 0bd0131

time=istep0*dt ! s

For our development configurations, time will equal 0 here since we have istep0 = 0 in the configuration.

It would be good to understand how this calendar call affects frz_onset, and whether our current setup where time=0 is correct.

[anton-seaice]

See CICE-Consortium/CICE#1068