Time-variant boundary variables

[pvanlaake]

Topic for discussion

The conventions state clearly that:

A boundary variable must have one more dimension than its associated coordinate or auxiliary coordinate variable.

CMOR (or fremetar, in the below example), however, will allow more dimensions in their boundary variables, in particular a "time" dimension, effectively making the boundary values time-variant (even though in many files the values do not vary over time). An excerpt from a GFDL data set:

netcdf pr_day_GFDL-ESM4_historical_r1i1p1f1_gr1_19760605-20021106 {
dimensions:
        bnds = 2 ;
        lat = 180 ;
        time = 9645 ;
        lon = 288 ;
variables:
        double bnds(bnds) ;
                bnds:long_name = "vertex number" ;
        double lat(lat) ;
                lat:long_name = "latitude" ;
                lat:units = "degrees_north" ;
                lat:axis = "Y" ;
                lat:bounds = "lat_bnds" ;
                lat:standard_name = "latitude" ;
                lat:cell_methods = "time: point" ;
        double lat_bnds(time, lat, bnds) ;
                lat_bnds:long_name = "latitude bounds" ;
        double lon(lon) ;
                lon:long_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:axis = "X" ;
                lon:bounds = "lon_bnds" ;
                lon:standard_name = "longitude" ;
                lon:cell_methods = "time: point" ;
        double lon_bnds(time, lon, bnds) ;
                lon_bnds:long_name = "longitude bounds" ;
        float pr(time, lat, lon) ;
                pr:_FillValue = 1.e+20f ;
                pr:long_name = "Precipitation" ;
                pr:units = "kg m-2 s-1" ;
                pr:cell_methods = "area: time: mean" ;
                pr:cell_measures = "area: areacella" ;
                pr:standard_name = "precipitation_flux" ;
                pr:interp_method = "conserve_order1" ;
                pr:original_name = "pr" ;
                pr:missing_value = 1.e+20f ;
        double time(time) ;
                time:long_name = "time" ;
                time:axis = "T" ;
                time:calendar_type = "noleap" ;
                time:bounds = "time_bnds" ;
                time:standard_name = "time" ;
                time:description = "Temporal mean" ;
                time:units = "days since 1850-01-01" ;
                time:calendar = "noleap" ;
        double time_bnds(time, bnds) ;
                time_bnds:long_name = "time axis boundaries" ;

// global attributes:
...
                :history = "File was processed by fremetar (GFDL analog of CMOR). TripleID: [exper_id_MFLg3OOf97,realiz_id_6UiFuoEKMa,run_id_PhuSv75why]" ;
...
                :Conventions = "CF-1.7 CMIP-6.0 UGRID-1.0" ;
...
                :grid = "atmos data regridded from Cubed-sphere (c96) to 180,288; interpolation method: conserve_order1" ;
                :grid_label = "gr1" ;
...

Seeing that this is a clear use-case, and with CMIP7 under preparation, is this something that should be considered for the conventions?

Pinging Karl @taylor13 specifically to invite you to elaborate on the rationale for including a time dimension in latitude and longitude boundary values. I scoured the CMIP6 documents but could not find a categorical rule that governs this.

[taylor13]

Actually, I think this is likely not a CF-compliant dataset, and I would note that the file wasn't written by CMOR but by the GFDL analog of CMOR (fremetar) . [For those unfamiliar with CMOR, it is software that has through various WCRP Coupled Model Intercomparison Project (CMIP) phases written petabytes of output from dozens of modeling groups, which is then analyzed by scientists worldwide. CMOR facilitates writing data in compliance with CF, and it includes multiple checks to catch errors in format and structure of metadata.]

One could have time as a dimension of the bounds on latitude and longitude, but then the latitude and longitude coordinates themselves would need to have a time dimension too (e.g., an "adaptive grid"). Such grids have not been used in previous CMIP phases, and we don't expect data to be reported on such grids in CMIP7.

[pvanlaake]

Hi Karl,

Thanks for your quick reply. This is apparently a non-issue for CF then. Closing this discussion.

I'll flag it to the GFDL folks for their follow-up.

Patrick