[BUG] Hourly frequency data: `time` coords and `time_bnds` related issue

[rhaegar325]

Describe the bug

According to our review and testing following dataset, in the ESM1.6 historical data:

/g/data/p73/archive/CMIP7/ACCESS-ESM1-6/development/historical-02

and the piControl data:

/g/data/p73/archive/CMIP7/ACCESS-ESM1-6/development/PI-CNP-concentrations-EarlyApril

time and time_0 are required by different variables. For example, 3hr.pr uses time_0 as its time coordinate, while some other variables, such as 3hr.huss, use time.

However, in the raw data variables section, only time_0_bnds is available. This causes time_bnds to be missing in the CMORised output.

The 6hr data has a similar issue, but in the opposite direction: it only contains time_bnds and is missing time_0_bnds.

3hr data

6hr data

[rbeucher]

Maybe something to flag with @joshuatorrance

[rbeucher]

It could be something that resolves itself with the split per year @blimlim what do you think?

[joshuatorrance]

um2nc is about to be updated so that atmosphere files in ESM1.6 are one "field" per file which will mean there won't be any time_X dimensions in the near future. We're intending to post-process the existing data for ESM1.6 using another script that splits multi-field nc files into single-field ones.

If this bug only affects ESM1.6 data then it may be a non-issue once all the single-field updates are deployed.

[blimlim]

With the 6hrly and 3hrly data, some of the variables were requested as means and others instantaneous snapshots. E.g. 3hrly surface pressure (fld_s00i409) is requested as instantaneous and rsds (fld_s01i235) is requested as a mean. This causes the time bounds to only be created for the time_0 variables (the means).

I think even after the changes for single variables, the instantaneous variables won't have time bounds, but possibly this is what we'd want?