Do restart files?

[timspainNERSC]

Following discussion with Francesca Vittorioso and Ali Aydogdu, check whether restart files created by the model do indeed restart the model state, upto the DG0 term.

[timspainNERSC]

Running consecutive runs with the following configurations works, with the correct value being read in from the model created restart file for the second run.

[model]
init_file = init_25km_NH.nc
start = 2010-01-01T00:00:00Z
stop = 2010-01-03T00:00:00Z
time_step = P0-0T00:15:00

[Modules]
DiagnosticOutputModule = Nextsim::ConfigOutput
DynamicsModule = Nextsim::DummyDynamics
IceThermodynamicsModule = Nextsim::ThermoWinton
AtmosphereBoundaryModule = Nextsim::ERA5Atmosphere
OceanBoundaryModule = Nextsim::TOPAZOcean

[ConfigOutput]
period = P0-0T1:00:00
start = 2010-01-01T00:00:00Z
field_names = hice,cice
filename = j23.restart2.nc

[ERA5Atmosphere]
file = 25km_NH.ERA5_2010-01-01_2011-01-01.nc

[TOPAZOcean]
file = 25km_NH.TOPAZ4_2010-01-01_2011-01-01.nc

[model]
init_file = restart2010-01-03T00:00:00Z.nc
start = 2010-01-03T00:00:00Z
stop = 2010-01-05T00:00:00Z
time_step = P0-0T00:15:00

[Modules]
DiagnosticOutputModule = Nextsim::ConfigOutput
DynamicsModule = Nextsim::DummyDynamics
IceThermodynamicsModule = Nextsim::ThermoWinton
AtmosphereBoundaryModule = Nextsim::ERA5Atmosphere
OceanBoundaryModule = Nextsim::TOPAZOcean

[ConfigOutput]
period = P0-0T1:00:00
start = 2010-01-03T00:00:00Z
field_names = hice,cice
filename = j23.restart2bis.nc

[ERA5Atmosphere]
file = 25km_NH.ERA5_2010-01-01_2011-01-01.nc

[TOPAZOcean]
file = 25km_NH.TOPAZ4_2010-01-01_2011-01-01.nc

[aydogduali]

Thanks @timspainNERSC & @einola, as @vittofra mentioned we have an issue with reproducing a long run solution by restarting using the below configuration file

The issue is that the difference is growing in time between a continuous run and restarted run as show here for the 4th day

We suspect that this may be related to the coordinate transformations between spherical and cartesian as maybe somehow discussed in #463 or #504 But it is only a guess.

@vittofra missed anything until this point?

[vittofra]

Thanks @aydogduali,

You basically said everything. I would just add that the restart files have fields identical to the output of the corresponding day, but, when using these files, they are perhaps read incorrectly by the model.

I would also specify that, in the 'develop' branch, today, you get two types of restart. When the [model] variable restart_period is not specified, then one only restart file is obtained ath the end of the run. This presents an exploitable format and is what we use for these tests. If, however, restart_period is made explicit, then one gets restart files (at the demanded frequency) that lack certain variables (i.e. lat, lon, azimuth) and are, therefore, not directly readable by the model.

[timspainNERSC]

If, however, restart_period is made explicit, then one gets restart files (at the demanded frequency) that lack certain variables (i.e. lat, lon, azimuth) and are, therefore, not directly readable by the model.

Oh!

That's the difference. And that is a problem I can look into and fix.

[aydogduali]

@einola, you have said that "Tim is right that the DG components are lost during the restart, but I don’t think that’s the problem." To iterate this point: do you think we should write the DG coefficients in the restarts to initialize properly? @ivopasmans-reading will also need them in the future for assimilation. @acarrassi

[timspainNERSC]

Yes, we definitely need the full set of DG components to be written to file. The changes to allow this are being undertaken as part of the overhaul of how files are written by nextSIM-DG to work with MPI and parallel netCDF. This work is being done by our colleagues at ICCS, especially @TomMelt and @jwallwork23.

[aydogduali]

Thanks a lot @timspainNERSC, all sounds good.

[timspainNERSC]

I think this issue is solved. While the full DG components are still missing, that is being worked on as part of another, larger issue.