Time units in ocean.stats.nc

[AndyHoggANU]

I find the ocean.stats.nc file to be a useful feature of MOM6 - but I have noticed that the time_units in this file differ from other diagnostics. Specifically, most diagnostics have time_units like 'days since 0001-01-01', while ocean.stats.nc just uses days (by default, or whatever is set in TIMEUNITS in MOM_input).

We only notice this issue because we are trying to access model output through a database; but it seems that we would benefit having a more standard time axis in ocean.stats.nc??

[aidanheerdegen]

Packages like xarray interpret the time axis as time deltas, as there is no reference time in the units.

>>> ds = xr.open_dataset('/g/data/v45/amh157/mom6/archive/tub-north-ref/output021/ocean.stats.nc')
>>> ds
>>> ds.Time
<xarray.DataArray 'Time' (Time: 7305)>
array([3313526400000000000, 3313548000000000000, 3313569600000000000, ...,
       3471249600000000000, 3471271200000000000, 3471292800000000000],
      dtype='timedelta64[ns]')
Coordinates:
  * Time     (Time) timedelta64[ns] 38351 days 00:00:00 ... 40177 days 00:00:00
Attributes:
    long_name:       Time
    cartesian_axis:  T

CF conventions state:

The reference time string (appearing after the identifier since) may include date alone; date and time; or date, time, and time zone. The reference time is required.

[adcroft]

I see your point. The history behind TIMEUNITS pre-dates adoption of standard units and was intended to allow more human-friendly number for the time values. I think we should be able to construct a more standard unit for the time in ocean_stats.nc.

[marshallward]

ocean_stats probably needs an overhaul anyway, e.g. @MJHarrison-GFDL did some very short runs and found a case where his answers changed but ocean_stats did not. We might need to include hashes for energy.

[MJHarrison-GFDL]

@marshallward . This test case is in Kate's repository . I found this whilst changing some parameters, first time I have come across this issue. Energy float values in ocean stats are identical to 12 significant digits. They differ at the 14th decimal place and in the energy hash reported to stdout.

[gustavo-marques]

Since we are talking about an overhaul: ocean.stats and ocean.stats.nc are overwritten every time the model restarts. It would be nice to have an option to append model year into these filenames (e.g., in energypath_nc) so they don't get overwritten.

[marshallward]

Looks like MOM_IC.nc/MOM.res.nc is also just using days for its units, which might be worth looking into.

[marshallward]

@gustavo-marques It looks to me like it's reopening the existing files and appending the results on a model restarts, not overwriting them.

I just tested this on a coupled run, but maybe you are seeing different behaviour in a different driver?

[gustavo-marques]

@marshallward Thanks for checking this. Yes, I am using a different so that might be the reason.
I will print day and CS%Start_time in here to find out what's happening.

[marshallward]

Should follow up here and say that it does look like there's some problems with ocean.stats and restarts... looks like the values are OK, but the first and last value inbetween runs is repeated, and the step counter is also not updated.

But maybe this is getting a bit too off topic and should be looked at in a separate issue.

In any case, I have a fix which should use CF time units in ocean.stats.nc, MOM_IC.nc and MOM.res.nc. Will try to get that in sometime early next week. (or perhaps a bit longer...)