The frequency in the intake catalog does not account for snapshot data

[minghangli-uni]

Is your feature request related to a problem? Please describe.

Snapshot diagnostics lack the time_bnds variable, causing the start_date and end_date from the intake-esm datastore to be incorrect.

One example is shown below, with the restart file access-om3.mom6.r.1915-01-01-00000.nc, where the output frequency is 2 hours and the total runlength is 30 hours, the start_date shows as 1915-01-01, 01:00:00 and the end_date is 1915-01-02, 07:00:00, instead of 1915-01-01, 00:00:00 and 1915-01-02 06:00:00.

path	realm	variable	frequency	start_date	end_date
xx	ocean	xx	2hr	1915-01-01, 01:00:00	1915-01-02, 07:00:00

Describe the feature you'd like

Properly parse the date info such as,

path	realm	variable	frequency	start_date	end_date
xx	ocean	xx	2hr	1915-01-01, 00:00:00	1915-01-02, 06:00:00

[marc-white]

@minghangli-uni could you provide the location of that file so I can have a play with it?

[dougiesquire]

I stupidly didn't think about snapshot data when writing get_timeinfo. There's some logic in there to try and guess the start and end dates when time bounds are not present, but I realise now that this will produce incorrect start and end dates for snapshot data. I guess this logic should probably just be removed (i.e. remove this), though that will mean the start and end dates will be wrong for non-snapshot output that doesn't provided time bounds...

[marc-white]

@minghangli-uni could you please point me towards the catalog this file is a part of?

[minghangli-uni]

Hi @marc-white, I generated those files myself. You can find those at /scratch/tm70/ml0072/access-om3/archive/expt14-perturb-1052c5ae/output003 for your reference.

[rbeucher]

My take on this is that we shouldn't try to guess the frequency if the time_bounds are missing so I would suggest removing the logic @dougiesquire is pointing out.

I would default to snapshot frequency if the time bounds are missing. I understand this will wrongly flag dataset as snapshots but this is a data definition problem.

@marc-white @charles-turner-1 .

[rbeucher]

Looks like we may need to handle restart files in a specific way though.

[charles-turner-1]

Also poses a problem for MOM6 data by the looks of it: see eg. annual data test and #292.