Name change of the pointer restart file

[anton-seaice]

In CESMCOUPLED, the name of the restart pointer file is being changed to include the datestamp.

See

CICE-Consortium/CICE#984

and

NCAR/MOM6#304

This will break restarts as they area. Well either need to change the caps/drivers to not include the datestamp, or update payu:

                self.rpointers.append(f"rpointer.{realm}")

(https://github.com/payu-org/payu/blob/7c885b855254ebb963c0a88d1f2ec306a026b71a/payu/models/cesm_cmeps.py#L101)

[anton-seaice]

I think my preference is to update the caps. Updating payu would mean figuring out what the timestamp should be on the rpointer files, which seems to defeat the purpose of having the pointer files.

[anton-seaice]

As noted above, all of the model components used for ACCESS-OM3 have been updated or will be updated to use restart pointer filenames which include a timestamp.

e.g.

what used to be rpointer.ice is for example becoming rpointer.ice.1900-02-01-00000

Currently there is a hardcoded assumption that the restart pointer filename is of the form rpointer.ice :

https://github.com/payu-org/payu/blob/27aac372dba2752e1d58ab1d66db799e7891e103/payu/models/cesm_cmeps.py#L101

The current system

The current system is neat in its way - there is one rpointer file for each model component, it contains the filename of the current restart file and is overwritten when a new restart file is made. As such the rpointer file always contains the filename of the latest restart file, and payu doesn't need to have any knowledge of the model date.

The new system

The new system makes this messy, as there will now be multiple rpointer files.

e.g. if I do two 1 months runs. I will have a

rpointer.ice.1900-02-01-00000
and a
rpointer.ice.1900-03-01-00000

And payu will need to figure out which one of them to keep. Payu would also need to update the pointer_file parameter in ice_in for CICE and possibly for other components (but MOM6 manages to figure out what it should be on its own!). This gets further complicated by the possibility of supporting saving extra restart files at intermediate points along a model run (e.g. monthly restart files for a run length of one year)

It looks like the restart pointer file for the mediator / cpl component might not include the timestamp ... see https://github.com/ESCOMP/CMEPS/blob/63a4a319c26a27a6790452043aa10e4b343ca29a/cesm/driver/esm_time_mod.F90#L134 and https://github.com/ESCOMP/CMEPS/blob/63a4a319c26a27a6790452043aa10e4b343ca29a/mediator/med_phases_restart_mod.F90#L306 so this file could act as a "source of truth" when figuring out the model date.

Possible fixes

1. Revert the change to the model components. This is ok but will get a bit messy as it involves introducing at #ifdef access3 statement or a new configuration option across about 5 different model components.
2. Update the model components to figure out what the restart pointer file should be based on the model time (which I guess can be found from the mediator's restart file, but we would want to confirm this upstream first.)
3. Update payu to figure out what the restart pointer files should be. This is simpler if we only support there being one restart more model run, if we want to save extra restarts per model run it might get more complicated. However getting payu to know the model date is messy (we battle this in esm1.5 a lot for example)

ping @aidanheerdegen @jo-basevi as this feels like your speciality a little !

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/22