Check_grid_mappping to include ocean model grids

[ssirviente]

We are currently validating datasets that include ocean variables produced with the NEMO ocean model using the tripolar ORCA12 grid. While running the quality checker, we noticed that the check_grid_mapping function currently restricts the accepted grid_mapping_name values to:

 # The allowed grid_mapping_name attribute values in CORDEX-CMIP6
    gmallowed = ["lambert_conformal_conic", "rotated_latitude_longitude"]

https://github.com/ESGF/cc-plugin-wcrp/blob/master/checks/attribute_checks/check_attrs_cordex_cmip6.py

From the current implementation, it appears that ocean grids can fail validation because check_grid_mapping only accepts lambert_conformal_conic and rotated_latitude_longitude, and also expects the presence of x/y or rlon/rlat coordinates. This works well for atmospheric regional climate model grids, but it prevents validation of ocean model outputs that use other types of grids (as tripolar), which are common in ocean modeling systems such as NEMO.

In our case:
• Model: NEMO
• Grid configuration: ORCA12
• Grid type: tripolar ocean grid
• Coordinates: curvilinear latitude and longitude (2D lat(y,x) and lon(y,x))

These grids are CF-compliant and widely used in ocean modeling, but they do not correspond to either lambert_conformal_conic or rotated_latitude_longitude.

So, would it be possible to extend the list of accepted grid types to support ocean grids? If so, whichgrid_mapping_nameand associated attributes would be expected for a tripolar grid?
Alternatively, should datasets with curvilinear latitude/longitude coordinates be treated as valid even when no projection-based grid_mapping is defined?
Or could we make the grid description not mandatory for ocean variables at this stage as this is not mandatory for CMIP7?

Thank you very much.

[larsbuntemeyer]

I suspect that this is probably an issue with sticking to the CORDEX-CMIP6 CV and its content. The grid mapping should actually be done in compliance checker parent CF check since this is more a definition in CF conventions.

[jesusff]

yes, but the CF conventions do not enforce the use of a grid_mapping, as we do in CORDEX at the moment

https://github.com/WCRP-CORDEX/archive-specifications/blob/cffaec0f4ab894baa798f94e8a56267a1623f721/docs/CORDEX-CMIP6_archiving_specifications_DD.md?plain=1#L169-L175

I was hoping that there could be a grid_mapping = "none" or some fallback option that we could use, but this would go against the CF conventions, so we cannot follow that path. On the other hand, relaxing the mandatory nature of the grid_mapping can lead to data actually projected on a plane pass the check without specifying the projection.

Ideally we could have a exception for certain variables, according to the realm/component, but this is not in the CMOR tables. Only a dirty hardcoded list would make it (or reading from an additional source, filtering the ocean component).

[ssirviente]

Would it be possible to follow an approach similar to CMIP7 and avoid making the grid_mapping universally mandatory?

Perhaps we could keep the requirement flexible and enforce it conditionally.
For example, require a grid_mapping only when the data are defined on a projected grid (e.g., atmospheric variables using planar coordinates such as x/y or rlon/rlat), while allowing datasets with curvilinear latitude/longitude coordinates (such as ocean tripolar grids) to pass validation without a projection definition.

This way, we could still prevent datasets that are actually projected on a plane from passing the check without specifying the projection, while remaining consistent with CF conventions and supporting ocean model grids that are not projection-based.

[jesusff]

Sara, could you post an ncdump -h of one of your files, so we have an idea of how are you currently defining the grid? The use of either x/y or rlat/rlon is also enforced at the moment. What coordinates are you using to index your lat/lon?

One possibility would be to allow for a third set of coordinates and use the presence of x/y or rlat/rlon to enforce the grid_mapping. Is this what you mean?

[ssirviente]

Yes sure! Our grid is defined only through 2D latitude and longitude (lat(y,x), lon(y,x)).

We discussed a possible solution to handle ocean grids more consistently, and trying to make it easy.

One idea that emerged is that it could be feasible to add a new column to the variable list indicating the type of realm (e.g. ocean, atmosphere, land, aerosols, river). Since this variable list is already used by the quality checker to verify whether a variable exists, it should not be difficult to use this additional column as a condition in the validation logic.

In practical terms, the checker could distinguish the type of variable based on this realm information. If the variable does not belong to the ocean realm, the quality checker would continue to operate as it currently does, requiring a valid grid_mapping. However, if the variable belongs to the ocean realm, the grid_mapping check could be skipped.

Instead, we could provide a description of the grid, for instance through the grid global attribute, which is currently present.

What do you think @jesusff ?

Here is the ncdump with the description included in the attribute grid :

ncdump -h so_MED-12_CNRM-ESM2-1_ssp585_r1i1p1f2_CNRM_CNRM-RCSM6-SN_v1-r1_day_19860101-19860630.nc
netcdf so_MED-12_CNRM-ESM2-1_ssp585_r1i1p1f2_CNRM_CNRM-RCSM6-SN_v1-r1_day_19860101-19860630 {
dimensions:
	deptht = 75 ;
	bnds = 2 ;
	y = 264 ;
	x = 567 ;
	time = UNLIMITED ; // (181 currently)
variables:
	double deptht(deptht) ;
		deptht:axis = "Z" ;
		deptht:bounds = "deptht_bnds" ;
		deptht:long_name = "Vertical T levels" ;
		deptht:name = "deptht" ;
		deptht:positive = "down" ;
		deptht:units = "m" ;
	double deptht_bnds(deptht, bnds) ;
	double lat(y, x) ;
		lat:_CoordinateAxisType = "Lat" ;
		lat:long_name = "Latitude" ;
		lat:standard_name = "latitude" ;
		lat:units = "degrees_north" ;
	double lon(y, x) ;
		lon:_CoordinateAxisType = "Lon" ;
		lon:long_name = "Longitude" ;
		lon:standard_name = "longitude" ;
		lon:units = "degrees_east" ;
	float so(time, deptht, y, x) ;
		so:standard_name = "sea_water_salinity" ;
		so:long_name = "Sea Water Salinity" ;
		so:units = "0.001" ;
		so:coordinates = "lat lon" ;
		so:_FillValue = 1.e+20f ;
		so:missing_value = 1.e+20f ;
		so:online_operation = "average" ;
		so:cell_methods = "area: mean where sea time: mean" ;
		so:interval_operation = "1 d" ;
		so:interval_write = "1 d" ;
		so:description = "Sea Water Salinity" ;
		so:history = "none" ;
		so:cell_measures = "area: areacello volume: volcello" ;
	double time(time) ;
		time:standard_name = "time" ;
		time:long_name = "Time axis" ;
		time:bounds = "time_bnds" ;
		time:units = "days since 1950-01-01 00:00:00" ;
		time:axis = "T" ;
		time:calendar = "standard" ;
	double time_bnds(time, bnds) ;

// global attributes:
		:CDI = "Climate Data Interface version 1.9.7.1 (http://mpimet.mpg.de/cdi)" ;
		:description = "CMIP6 historical" ;
		:data_specs_version = "01.00.21" ;
		:dr2xml_version = "2.0" ;
		:experiment_id = "historical" ;
		:frequency = "day" ;
		:institution_id = "CNRM" ;
		:product = "model-output" ;
		:realization_index = 1 ;
		:realm = "ocean" ;
		:table_id = "Noneday" ;
		:variable_id = "so" ;
		:xios_commit = "1442-shuffle" ;
		:creation_date = "2020-04-28" ;
		:EXPID = "RCSM6-HIS" ;
		:CDO = "Climate Data Operators version 1.9.7.1 (http://mpimet.mpg.de/cdo)" ;
		:NCO = "\"4.6.2\"" ;
		:grid = "NEMO ORCA tripolar grid with a 1/12 degree (6-8km) horizontal resolution" ;
		:source = "Version 6 of the fully-coupled Regional Climate System Model (RCSM) of the Centre National de Recherches Meteorologiques (CNRM)" ;
		:institution = "Centre National de Recherches Meteorologiques, Toulouse, France" ;
		:Conventions = "CF-1.11" ;
		:activity_id = "DD" ;
		:contact = "contact.cordex@meteo.fr" ;
		:comment = "CNRM-RCSM6 model output prepared for CMIP6 and CORDEX / ssp585 simulation" ;
		:driving_experiment = "update of RCP8.5 based on SSP5" ;
		:source_id = "CNRM-RCSM6-SN" ;
		:project_id = "CORDEX-CMIP6" ;
		:mip_era = "CMIP6" ;
		:license = "https://cordex.org/data-access/cordex-cmip6-data/cordex-cmip6-terms-of-use" ;
		:domain_id = "MED-12" ;
		:domain = "Mediterranean" ;
		:driving_experiment_id = "ssp585" ;
		:driving_institution_id = "CNRM-CERFACS" ;
		:driving_source_id = "CNRM-ESM2-1" ;
		:driving_variant_label = "r1i1p1f2" ;
		:source_type = "AORCM" ;
		:version_realization = "v1-r1" ;
		:references = "Sevault F. (2024). Atlas of the 1980-2018 ERA-Interim simulation with the coupled regional climate system model CNRM-RCSM6. Zenodo. https://doi.org/10.5281/zenodo.10726156" ;
		:tracking_id = "hdl:21.14103/479c85d4-ff37-4bf8-97a2-d4542413bb63" ;
}

[jesusff]

Thanks for the example. I see you use x/y so my previous idea does not fit. I think the checker is not reading the data request files, where we will have an ocean component (WCRP-CORDEX/data-request-table#68), but the CMOR tables (@sol1105 ?).

In the CMOR table we could use the cell_measure (areacello) or cell methods ("where sea") to tell the ocean variables apart:
https://github.com/WCRP-CORDEX/cordex-cmip6-cmor-tables/blob/9b6bc0949f52120cb7a019f78e9c71c559f0659c/Tables/CORDEX-CMIP6_day.json#L3481-L3497

Instead, we could provide a description of the grid, for instance through the grid global attribute, which is currently present.

Yes, the grid attribute is recommended, with a text description of the grid used. Is your example passing the checker? You might need to change it to something like: "NEMO ORCA tripolar grid with a 1/12 degree (6-8km) grid spacing"

cc-plugin-wcrp/checks/attribute_checks/check_attrs_cordex_cmip6.py

Lines 356 to 358 in 8e4454c

	if grid:
	# Check if grid description is following the examples
	if re.fullmatch(r"^.* with .* grid spacing.*$", grid):

If we request it mandatorily for ocean grids, it could be used to skip the grid_mapping issue by checking if terms such as "tripolar" appear in the grid attribute. This could be the cleanest way to proceed.

[sol1105]

@jesusff Yes, currently the CMOR tables are still read in. In the near- to midterm esgvoc will be the base of the variable information also for the wcrp_cordex_cmip6 checker, as it is already the case for the wcrp_cmip6 and wcrp_cmip7 checkers.

[jesusff]

Thank you, Martin. esgvoc seems less convenient at the moment, especially until we fully adopt other CMIP7 practices (branded variables, grids, ...). E.g. the variable does not have a clear declaration of being from the ocean component:

https://github.com/WCRP-CMIP/WCRP-universe/blob/esgvoc/variable/so.json

What do you think of the grid solution? to me, this would be the cleanest way at the moment. I did a tentative PR here #40

[ssirviente]

@jesusff

Indeed, in my example we do obtain the recommendation for the grid attribute, and what we did was to add the description including the grid spacing, following the suggested format. We are currently looking into how to define it in the best possible way, so thank you very much for your recommendation , it is very helpful.

At the moment, the only remaining error we are encountering is the one related to the grid mapping checker.

I agree that making the grid attribute a mandatory requirement makes sense, as it would allow us to clearly differentiate between oceanic variables and non-oceanic ones, helping to avoid the issue you mentioned, where data that are actually projected on a plane pass the check without specifying the projection.

I think using cell_methods ("where sea") is a better approach. I have checked the CMOR tables, and some ocean variables such as tauvo, tauuo, uos, and vos do not have cell_measures (areacello) defined.

We should also note that this solution would work for ocean variables, but it is not yet clear whether it would apply to river variables, as these can also have specific grid configurations. In our case, the river variables are defined on a regular 1/2° latitude–longitude grid. At the moment, I do not see these river variables included in the CMOR tables, but I assume they will be incorporated at some point.

Possibly, for river variables that will have areacellr, the use of cell_measures could be appropriate.

I think that, with this approach, the solution would essentially involve implementing a conditional rule in the QC process such as:

If the variable is oceanic, then the grid mapping checker would not be applied, but the grid attribute checker would be required.
Otherwise, the current procedure would remain unchanged, ensuring that projected data continue to follow the grid mapping checker.

[jesusff]

I'm afraid that we cannot rely on the fact that a variable is oceanic to skip the planar projection. @sol1105 provides here (#40 (comment)) an example of a group interpolating their ocean variables to the rotated lat-lon grid, thus requiring the grid_mapping. So it is not the variables themselves calling for a non-projected grid, but the grid itself needs to be checked. I could imagine that there is a regional ocean model with a projected grid or that there are groups preferring to deliver the ocean variables on the same grid as the atmospheric variables.

[ssirviente]

I understand your point so, we cannot rely on the variable type alone to decide whether a projected grid (and thus a grid_mapping) is required. As you mention, some groups do interpolate ocean variables onto the atmospheric grid, so in those cases the grid_mapping is indeed necessary.

At the same time, there are also groups (like ours) that provide ocean or river variables on their native grids, without any projection, and therefore without a grid_mapping.

So instead of making a decision purely based on the variable, we could slightly refine the checker logic to account for both situations in a simple way:

• If the variable has a grid_mapping
  → perform the current checks as they are now (no change)
• If the variable does not have a grid_mapping
  → allow it only if it is clearly oceanic or river-related (based on metadata such as cell_methods="where sea" or cell_measures including areacellr)
  → otherwise, raise a failure

And similarly for the grid definition:

• If a projected grid is used (grid_mapping_name present)
  → require the corresponding coordinates (x/y or rlat/rlon), as currently implemented
• If no projected grid is defined
  → allow missing projected coordinates only for ocean/river variables

In this way, we still enforce strict checks when a projected grid is actually used, while avoiding checker for valid ocean/river datasets that do not define a projection.
What do you think? @jesusff @sol1105