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:
|
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:
|
time = runtime0 !............ |
And the model date is only correctly initialised at this later calendar call which still happens before the model starts running:
|
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:
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.
See here for more background.
The
frz_onsetfield records the day of year when ice first forms on a gridcell, either via congel or frazil.The
frz_onsetoutput has a strange dependence on the early steps of the calendar initialisation. In particular, during theinit_restartsubroutine, there is the following call to thecalendarsubroutine:cice5/drivers/access/CICE_InitMod.F90
Lines 364 to 369 in 0bd0131
From the tests described here,
frz_onsettakes different values based on whethertimeis 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
timeat 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
And the model date is only correctly initialised at this later
calendarcall which still happens before the model starts running:cice5/drivers/access/CICE_InitMod.F90
Line 215 in 0bd0131
With the original calendar setup (i.e. from CM2), the
timeargument will come from an earlier call toinit_calendar:cice5/source/ice_calendar.F90
Line 133 in 0bd0131
For our development configurations,
timewill equal 0 here since we haveistep0 = 0in the configuration.It would be good to understand how this calendar call affects
frz_onset, and whether our current setup wheretime=0is correct.