blimlim
commented
2 months ago I think I have a better idea now of how Cice uses the conflicting cice_in.nml and input_ice.nml namelists produced by payu.
Cice only uses the stop_now condition, which is controlled by the value of npt, for non-ACCESS simulations:
https://github.com/ACCESS-NRI/cice4/blob/e7549ebd2044690a432cc67c1317c81cb194b750/drivers/access-cm/CICE_RunMod.F90#L334C1-L344C42
timeLoop: do
call ice_step
istep = istep + 1 ! update time step counters
istep1 = istep1 + 1
time = time + dt ! determine the time and date
call calendar(time) ! at the end of the timestep
if (stop_now >= 1) exit timeLoopFor ACCESS simulations, I think it uses the coupling information to control the length of the ice time loop instead.
#ifdef AusCOM
time_sec = 0
...
DO icpl_ai = 1, num_cpl_ai !begin A <==> I coupling iterations
Do icpl_io = 1, num_cpl_io !begin I <==> O coupling iterations
...
do itap = 1, num_ice_io ! cice time loop within each i<=>o cpl interval
...
call ice_stepso for ESM1.5, the number of ice timesteps should be num_cpl_ai * num_cpl_io * num_ice_io, and these values appear to be calculated from the input_ice.nml namelist – in particular using the runtime variable set by payu's access.py
num_cpl_ai = runtime/dt_cpl_ai
num_cpl_io = dt_cpl_ai/dt_cpl_io
num_ice_io = dt_cpl_io/dt_ciceE.g. we'll have the total number of cice timesteps as num_cpl_ai * num_cpl_io * num_ice_io = runtime/dt_cice, and so modifying npt in cice_in.nml (as in the above comment) won't affect the simulation length, but modifying runtime in input_ice.nml will.
There's still the question of why the ice_diag.d logs stop getting lines like istep1: 35040 idate: 1041231 sec: 0 written to it after npt time steps. These lines are written in the calendar subroutine, but only when the stop_now condition is false
if (my_task == master_task .and. mod(istep,diagfreq) == 0 &
.and. stop_now /= 1) then
write(nu_diag,*) ' '
write(nu_diag,'(a7,i10,4x,a6,i10,4x,a4,i10)') &
'istep1:', istep1, 'idate:', idate, 'sec:', sec
endifso although the simulation length is controlled by runtime, npt controls how long these lines are written for.
Payu's handling of the cice calendar is a bit confusing, especially around leap years. It would be good to clarify how the calendar is controlled, and whether we should make any changes. I'll note down here what I've understood so far - please add any clarifications, or ideas that you have!
What I've had the most trouble understanding is the inconsistencies between the
cice_in.nmlandinput_ice.nmlconfiguration files, and the way thatcice.pyandaccess.pyin payu handle them during thesetupstage.cice.py:
cice.pystarts by setting the experiment initialisation date and calendar type usingcontrol-dir/ice/cice_in.nml: https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/cice.py#L159-L165With the current version of
cice_in.nmlin the esm1.5 configs, this sets it to a 365 day calendar:It then reads
istep0andnptfromrestart-dir/cice_in.nmlto calculate the amount of time already simulated since the initialisation date:https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/cice.py#L211-L215
and uses the result to set the new simulation's starting date. This start date, plus the runtime specified in the
config.yamlfile, are used to calculate the new simulation's run duration (in seconds, using a 365 day calendar).https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/cice.py#L227-L240
Finally it writes the number of time steps corresponding to this duration to
nptinwork-dir/ice/cice_in.nml:https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/cice.py#L242-L245
Because of the 365 day calendar setting,
cice.pyalways setsnptto 8760. E.g. for a four year simulation starting at year 101, the values produced are:access.py
access.pyrepeats similar calculations usinginput_ice.nml.It first reads the calendar type and experiment initialisation date from
control-dir/ice/input_ice.nml, which setscaltype = 1, corresponding (I think?) to a proleptic gregorian calendar.Using the
runtime0andruntimevalues inrestart-dir/ice/input_ice.nml, it calculates the start date of the new simulationhttps://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/access.py#L138-L143
and then the run duration of the new simulation using the
config.yamlsettings:https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/access.py#L150-L157
all using the proleptic gregorian calendar.
The previous simulation length, new start date, and new simulation length are then written to
work-dir/ice/input_ice.nml:https://github.com/payu-org/payu/blob/ef55e93fe23fcde19024479c0dc4112dcdf6603f/payu/models/access.py#L161-L164
which takes leap years into account:
Along with the different calculations, the versions of
cice_in.nmlandinput_ice.nmlin the initial pre-industrial restarts in/g/data/vk83/experiments/inputs/access-esm1p5/pre-industrial/restart/icedon't match upand so
cice.pydoes its calendar calculations using a start date of 0001-01-01, whileaccess.pyuses 0101-01-01. This doesn't seem to cause issues ascice.pyuses the 365 day calendar anyway and doesn't write the calculated start date anywhere. We could editcice_in.nmlto have the correct prior run length, though that might make it more confusing asistep0would have to be set according to a 365 day calendar, and wouldn't line up withruntime0's value which uses the proleptic Gregorian calendar.With these inconsistencies, it would be great to understand which information the
cicemodel is actually using during simulations.From a quick look at the cice code, I thought it might be using
nptto control the duration.In year 104, the model stops writing to the
ice.diag.dfile after 365 days withdiagfreqset to 1 incice_in.nml:however hourly model output is saved right up to the end of the year:
and so it does appear to find the correct 366 run length somewhere.