netCDF dimensions for single level variables

[charliepascoe]

There seems to be an inconsistency between the list of dimensions that we expect to appear in single-level netCDF files and the information about the same single-level variables in the ccmi-2022 MIP tables.

An example is the Aday variable ta500.
In the Aday MIP table, ta500 has the dimensions: "longitude latitude time1 p500" which implies that the pressure level should appear as a dimension in the netCDF file. However, the ceda-cc checks expect the pressure level to appear as a coordinate attribute.

I think this discrepancy is at the root of the metadata "errors" that ceda-cc is detecting in the NIES data #54 #51 .
It seems to me that Hideharu is following the rules of the MIP table, it is just that those rules are not the same as the conventions that we actually want the data to follow.

        "ta500": {
            "frequency": "dayPt",
            "modeling_realm": "atmos",
            "standard_name": "air_temperature",
            "units": "K",
            "cell_methods": "area: mean time: point",
            "cell_measures": "area: areacella",
            "long_name": "Air Temperature at 500hPa",
            "comment": "Air temperature on the 500 hPa surface",
            "dimensions": "longitude latitude time1 p500",
            "out_name": "ta500",
            "type": "real",
            "positive": "",
            "valid_min": "",
            "valid_max": ""

[ccmi1-test]

Hi Charlotte

Looking into the CF conventions document (Section 2.4), there is the following:

Dimensions may be of any size, including unity. When a single value of some coordinate applies to all the values in a variable, the recommended means of attaching this information to the variable is by use of a dimension of size unity with a one-element coordinate variable. It is also acceptable to use a scalar coordinate variable which eliminates the need for an associated size one dimension in the data variable.

Including p500 as a dimension of size one (and not as a scalar coordinate) would also seem to conform to the CF conventions, I guess?? But it does add the complication that people reading the data need to define the variable with this extra dimension of size one which can be a pain when working with a mixture of different approaches.

And I will also add, the CCMI-2022 tables with this extra dimension tacked on the end follows numerous similar examples in the CMIP6 MIP tables. And when I used CMOR3 for CCMI-2022 it seemed to recognize p500 as a scalar coordinate and added the appropriate coordinate attribute.