Incorrect time-stamp for MOM6 restart files

[micaeljtoliveira]

Seems like the MOM6 restart filename does not have the correct timestamp. Regardless of the actual simulation time, the file seems to always have seconds set to 0. This is probably not an issue if a calculation runs for more than one simulation day, but otherwise the code might try to write a new restart file with the same name as the previous restart file, causing an error.

[ezhilsabareesh8]

I am able to reproduce this timestamp issue when running the configuration for two time steps. While the CICE component display timestamps 7200 and 14400 (e.g., GMOM_JRA.cice.r.0001-01-01-07200.nc and GMOM_JRA.cice.r.0001-01-01-14400.nc) after the first and second runs respectively, MOM6's timestamps remain 0000 for both runs.

This inconsistency causes a problem during the second run, as MOM6 attempts to overwrite the file with the same name as the first run, leading to a error. The error arises due to the identical file names (GMOM_JRA.mom6.r.0001-01-01-00000.nc).

This issue specifically occurs when the restart time interval is less than a day. In contrast, the problem doesn't arise when the restart time interval is more than a day since the filenames include the day, differentiating them (e.g., GMOM_JRA.mom6.r.0001-02-01-00000.nc and GMOM_JRA.mom6.r.0001-03-01-00000.nc).

It is found that the timestamp handling is unused in the MOM6 NUOPC cap at present (Reference) . The time_stamped flag is not passed to save_restart function (Reference). At present, the flag is set to false by default.

The ocean_model_restart function need to be modified to enable the timestamp when generating restart filenames.

[dougiesquire]

It's pretty strange that the timestamp flag is there but unused. There's even a comment in the code that "(Currently this is unused.)" so it's deliberately unused, not a bug. On face value, this seems like something that should be easy to add, which makes one wonder why it wasn't done in the first place...

[aekiss]

Interesting - I guess we could try fixing this and see what happens? Will we also need to modify the routine that finds/reads the restart?

[ezhilsabareesh8]

Thanks @aekiss and @dougiesquire, I've identified and resolved the timestamp issue encountered in the configuration. The ocean_model_restart function directly passes the filename to the save_restart function. As such, no time_stamp flag was needed. The bug was actually located within mom_cap.f90 and was affecting the generation of restart file names using the ESMF_TimeGet function.

The problem stemmed from how ESMF_TimeGet handles units (reference). When calling ESMF_TimeGet to determine the restart file name, units are bound by the next larger specified unit. This led to a situation where the timestamp's seconds component was unintentionally set to zero, causing filenames like GMOM_JRA.mom6.r.0001-01-01-00000.nc.

To rectify this, I made a modification in the ModelAdvance function within mom_cap.f90. I adjusted the line from:

call ESMF_TimeGet (MyTime, yy=year, mm=month, dd=day, h=hour, m=minute, s=seconds, rc=rc ) Refer here

to: call ESMF_TimeGet(MyTime, yy=year, mm=month, dd=day, s=seconds, rc=rc )

By making this change, I ensured that the seconds component remains consistent, providing filenames in the format GMOM_JRA.mom6.r.0001-01-01-07200.nc for the first run and GMOM_JRA.mom6.r.0001-01-01-14400.nc for the second run. This aligns with the filenames of CICE components and eliminates the error caused by overwriting files with identical names when the configuration is run for two time steps.

I can make this changes in access-om3 repo by creating a copy of mom_cap.f90 within the extra_sources directory of MOM6.

[dougiesquire]

Great work @ezhilsabareesh8. This sounds like something we should probably contribute back into the authoritative codebase in the long run.