how to handle pressure levels

larsbuntemeyer commented 2 years ago

how do de handle pressure levels? I guess we can take something like ta700 from CMIP6_CFday.json as an example:

"ta700": {
            "frequency": "day", 
            "modeling_realm": "atmos", 
            "standard_name": "air_temperature", 
            "units": "K", 
            "cell_methods": "area: time: mean", 
            "cell_measures": "area: areacella", 
            "long_name": "Air Temperature", 
            "comment": "Air temperature at 700hPa", 
            "dimensions": "longitude latitude time p700", 
            "out_name": "ta700", 
            "type": "real", 
            "positive": "", 
            "valid_min": "", 
            "valid_max": "", 
            "ok_min_mean_abs": "", 
            "ok_max_mean_abs": ""
        },

with an entry in CMIP6_coordinates.json like this:

"p700": {
            "standard_name": "air_pressure", 
            "units": "Pa", 
            "axis": "Z", 
            "long_name": "pressure", 
            "climatology": "", 
            "formula": "", 
            "must_have_bounds": "no", 
            "out_name": "plev", 
            "positive": "down", 
            "requested": "", 
            "requested_bounds": "", 
            "stored_direction": "", 
            "tolerance": "", 
            "type": "double", 
            "valid_max": "", 
            "valid_min": "", 
            "value": "70000.", 
            "z_bounds_factors": "", 
            "z_factors": "", 
            "bounds_values": "", 
            "generic_level_name": ""
        },

larsbuntemeyer commented 2 years ago

Note that the pressure level is only mentioned in the comment attribute not in the long_name attribute (as opposed to the variables on height levels, see WCRP-CORDEX/cordex-cmip6-cmor-tables#31 )

wachsylon commented 2 years ago

Can we guarantee that whenever integers are inside the variable name they refer to the variable's vertical level? Is that a clear rule for variable names?

I provide intake catalogs where files are aggregated to datasets. The attributes of the files used to group files to a dataset (should) comprise only path and filename information. Since the vertical axis is not part of the path and filename information, intake tries to merge different variables (e.g. ta700 and p850) on their shared vertical axis plev. This is not feasible or possible - e.g. ta700 and p850 should not have a shared vertical axis with nan values on their un-shared level.

If the level information could be deduced from the data standard (i.e. filename), that would be helpful when creating such a catalog. However I may have to parse the MIP-Tables in the end anyway... :)

larsbuntemeyer commented 2 years ago

Can we guarantee that whenever integers are inside the variable name they refer to the variable's vertical level? Is that a clear rule for variable names?

I see two problems there with od550aer (550 refers to wavelength) and z0 at least....

gnikulin commented 2 years ago

I think there are no clear rules and in addition to the above examples there are a number variables in CMIP6 with digits in their names not representing vertical levels.

WCRP-CORDEX / cordex-cmip6-cmor-tables

how to handle pressure levels #30