Hardcode date_init to year 0 ?

[anton-seaice]

In cice, date_init is the reference time for dates. i.e. all dates are defined as seconds since date_init.

In cice4 and cice5, this is configurable. In cice6, it is just hardcoded to year 0. There is no reason to every change it. You can have >200 000 years when counting seconds before overflowing a double float.

In esm1.5 (cice4), we are tracking the value of date_init in a seperate restart_date.nml file to ensure that restart information has dates with it. This means the restart_date.nml needs to be kept with every restart file.

For esm1.6 (probably cice5), there are no existing restart files using cice5, so I suggest we just hardcode the value of date_init now. Access-OM2 and some esm1.5 configurations use date_init of 1 ... there is probably no reason not to just set date_init to 0? (With date_init of 0, the restart time can be found in a cice5 restart file).

ping @blimlim

[anton-seaice]

Oh - hardcoding to year 1 would be consistent with the OM2 config, so maybe would mean the change can go in "master" as well as the "esm1.6" branch.

[anton-seaice]

It looks like it's set to 0001 in OM2:

https://github.com/ACCESS-NRI/cice5/blob/a09f25ccebc43a4d47bb8b2bf1bd00f610062aae/drivers/access/cpl_parameters.F90#L64C27-L64C36

And not changed in the config

So maybe we can hardcode to 0001 ?

[anton-seaice]

@blimlim ?

[blimlim]

Sorry this could be a bit overkill, but I thought it would be good to understand how much simplifying we could do. We're currently using the restart_date.nml for both the init_date and the inidate, and so would be great if it's possible to remove both. Have had a dig and think I understand how the date/time is being controlled.

I guess the things we want to control are:

• The internal model time variable, measuring the seconds since some reference date
• The internal model date, used to control when history and restart files are written
• The history file dates
• The restart file names (e.g. iced.0789-02-01-00000.nc)
• The time and date information written to the restart file.

As you pointed out, some of this information is requiring us to carry around an extra restart_date.nml file, and it would be better if we could instead initialise all of this based on a combination of hard-coded data and the data in the previous netCDF restart file.

Diagram of current time/date control in the coupled model:

There are three sources of information that are used by the coupled driver to set up these things:

• The restart_date.nml, which is used by payu to produce the input_ice.nml namelist in the work directory containing:
  • init_date: experiment initialisation date
  • inidate: start date for new experiment
  • runtime0: Seconds since init_date at start of new experiment. I.e. seconds between init_date and inidate.
• The previous netCDF restart file contains:
  • time: The same as runtime0
  • Date information nyr, month, mday, sec. This equals the date for the restart only when cice_in.nml/ year_init == 1. Otherwise the nyr component equals the year relative to year_init. Because of this reliance on the namelist, I don't think this date is very reliable to use.
• The cice_in/ year_init namelist option. As far as I can tell, in the coupled setup this only affects whether the dates in the restart files match the actual model date or not. In the non-coupled set up it looks like this impacts the inital date.

The time information in the previous restart file is ignored. Instead almost everything is taken from restart_date.nml/input_ice.nml

Details of current calculations:

Internal model time, time:

During initialisation time is set to equal runtime0 from the ice_input.nml namelist:

cice5/drivers/access/CICE_InitMod.F90

Line 192 in 15fa7de

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

when jobnum != 1. This happens after the restart is read, meaning that the time value from the restart file is thrown out.

During the timestep loop, time is incremented by dt:

cice5/drivers/access/CICE_InitMod.F90

Line 208 in 15fa7de

time = time + dt ! determine the time and date

and during the run, time will represent the number of seconds since the init_date.

Internal model date:

The internal model date is calculated during each timestep's call to calendar:

cice5/drivers/access/CICE_InitMod.F90

Line 214 in 15fa7de

call calendar(time-runtime0)

Notably, calendar is called with input time-runtime0, i.e. the time since the start of the run.

calendar uses the get_idate subroutine to calculate newy, newm, newd, newh which are the year, month, day of month, and hour of day at the current time.

The calculation itself took me a while to understand, however it's starting with inidate from the input_ice.nml namelist, advancing time-runtime0 seconds, and calculating the new date.

History file time:

The netCDF history variables set their time variable using the model time variable

cice5/io_netcdf/ice_history_write.F90

Lines 117 to 129 in 15fa7de

	#if defined(AusCOM) || defined(ACCESS)
	! set timestamp in middle of time interval
	if (histfreq(ns) == 'm' .or. histfreq(ns) == 'M') then
	if (month /= 1) then
	ltime=time/int(secday)-real(daymo(month-1))/2.0
	else
	ltime=time/int(secday)-real(daymo(12))/2.0
	endif
	else if(histfreq(ns) == 'd' .or. histfreq(ns) == 'D') then
	ltime=time/int(secday) - 0.5
	else
	ltime=time/int(secday)
	endif

It sets the time origin as idate0

cice5/io_netcdf/ice_history_write.F90

Lines 204 to 209 in 15fa7de

	write(cdate,'(i8.8)') idate0
	write(title,'(a,a,a,a,a,a,a,a)') 'days since ', &
	cdate(1:4),'-',cdate(5:6),'-',cdate(7:8),' 00:00:00'
	status = nf90_put_att(ncid,varid,'units',title)
	if (status /= nf90_noerr) call abort_ice( &
	'ice Error: time units')

which (only) for ACCESS, is just init_date:

cice5/source/ice_calendar.F90

Line 201 in 15fa7de

idate0 = init_date

so the history file time is based on the internal time variable and the input_ice.nml init_date value.

Restart file names:

The restart filename is set entirely based on the internal model date:

cice5/io_netcdf/ice_restart.F90

Lines 152 to 155 in 15fa7de

	write(filename,'(a,a,a,i4.4,a,i2.2,a,i2.2,a,i5.5)') &
	restart_dir(1:lenstr(restart_dir)), &
	restart_file(1:lenstr(restart_file)),'.', &
	iyear,'-',month,'-',mday,'-',sec

Time and date information in the restart file:

cice5/io_netcdf/ice_restart.F90

Lines 170 to 176 in 15fa7de

	status = nf90_put_att(ncid,nf90_global,'istep1',istep1)
	status = nf90_put_att(ncid,nf90_global,'time',time)
	status = nf90_put_att(ncid,nf90_global,'time_forc',time_forc)
	status = nf90_put_att(ncid,nf90_global,'nyr',nyr)
	status = nf90_put_att(ncid,nf90_global,'month',month)
	status = nf90_put_att(ncid,nf90_global,'mday',mday)
	status = nf90_put_att(ncid,nf90_global,'sec',sec)

• time is just set as the internal model time, i.e. seconds since init_date.
• month month, day of month mday, and seconds into the day sec are just set from the internal model date.
• Year nyr is (unfortunately?) not set from the internal model date. It instead uses the nyr variable which is related to the actual year by:

  cice5/source/ice_calendar.F90

  Line 264 in 15fa7de

  nyr = newy - year_init + 1

  
  where newy is the actual model year.

When year_init=1 from the cice_in.nml (which it usually is), nyr equals the internal model calendar. Otherwise it can be offset from the actual year by some arbitrary number of years.

Ideas for changes:

One option to remove the dependence on restart_date.nml/input_ice.nml would be to:

1. Hardcode init_date=00010101 as suggested!
2. Initialise the time variable from the previous restart, rather than from runtime0 in restart_date.nml/input_ice.nml.
3. Calculate inidate at model initialisation as the init_date plus the time in the previous restart. I think this is safer than using the month, nyr etc data from the restart file due to it's dependence on the year_init namelist option.

I think the code changes would be pretty minimal for this and would let us simplify the payu driver quite a bit. This is probably good enough for getting things going for the swap to CICE5 in ESM1.6.

If we ended up with some free time in the future, we could look at simplifying the calendar calculations being done internally in CICE, but that would be more of a nice to have thing after the user facing changes are in.

[blimlim]

After attempting to implement this, I'm thinking it might be nicer to instead:

1. Hardcode init_date=00010101 as suggested.
2. Initialise the time variable from the previous restart, rather than from runtime0 in restart_date.nml/input_ice.nml.
3. Enforce year_init=1 in the cice_in.nml namelist (or even hard code it). This ensures that the date variables in the restart file are correct.
4. Set inidate from the date in the restart files.

This avoids a few annoying calculations (i.e. recalculating inidate), and also makes the payu implementation simpler (e.g. we're already using the date in the restart file in the payu branch, and so we're already assuming that year_init is fixed at 1).

[blimlim]

3. Enforce year_init=1 in the cice_in.nml namelist (or even hard code it). This ensures that the date variables in the restart file are correct.

Or instead always write the correct year to the restart file, so that the year_init setting doesn't matter.

[anton-seaice]

Is nyr used for anything ? If it's just for user information, having the actual year in the restart would be more useful

[blimlim]

nyr is used to check when the model crosses into a new year:

cice5/source/ice_calendar.F90

Line 302 in 90a7164

if (nyr /= nyrp) new_year = .true.

This would still work fine if we replaced it with the actual year.

It is also used in ice_forcing.F90

cice5/source/ice_forcing.F90

Line 167 in 90a7164

fyear = fyear_init + mod(nyr-1,ycycle) ! current year

This would change if we swapped it to the actual year, but I'm guessing we aren't using this part of the code?

[anton-seaice]

We aren't using ice_forcing in the coupled model, its possible (but probably unlikely) that's used in OM2 (if we end up merging branches). Because there is not a strong reason to change nyr, my feeling is leave it alone so we don't break something.

[anton-seaice]

Does use_restart_time = .false. still work ? I guess this is the case where year_init in the cice namelist is used ? (Otherwise it's ignored ?)

[blimlim]

Because there is not a strong reason to change nyr, my feeling is leave it alone so we don't break something.

I think we will need to still change what's written for the year in the restart file, otherwise the new payu run-length calculation isn't guaranteed to work.

We can still do this without changing nyr though, e.g. I've been testing the following change:

cice5/io_netcdf/ice_restart.F90

Lines 187 to 192 in 2c2c80b

	#ifdef AusCOM
	iyear = nyr + year_init - 1
	status = nf90_put_att(ncid,nf90_global,'nyr',iyear)
	#else
	status = nf90_put_att(ncid,nf90_global,'nyr',nyr)
	#endif

in the same way that the name of the restart files are already given the correct year:

cice5/io_netcdf/ice_restart.F90

Lines 148 to 155 in 90a7164

	iyear = nyr + year_init - 1
	imonth = month
	iday = mday
	write(filename,'(a,a,a,i4.4,a,i2.2,a,i2.2,a,i5.5)') &
	restart_dir(1:lenstr(restart_dir)), &
	restart_file(1:lenstr(restart_file)),'.', &
	iyear,'-',month,'-',mday,'-',sec