Esmvaltool: Data standard issue with AWI-CM-1-1-MR and AWI-ESM-1-1-LR

[ledm]

Just encoutered a data standard issue with AWI-CM-1-1-MR and AWI-ESM-1-1-LR models.

Specifically, the files (on jasmin):

/badc/cmip6/data/CMIP6/CMIP/AWI/AWI-CM-1-1-MR/historical/r3i1p1f1/Omon/tos/gn/latest/tos_Omon_AWI-CM-1-1-MR_historical_r3i1p1f1_gn_199101-200012.nc

/badc/cmip6/data/CMIP6/CMIP/AWI/AWI-ESM-1-1-LR/historical/r1i1p1f1/Omon/tos/gn/latest/tos_Omon_AWI-ESM-1-1-LR_historical_r1i1p1f1_gn_199101-200012.nc

The latitude and longitude share a dimension,. ie:

sea_surface_temperature / (degC)    (time: 120; -- : 830305)
     Dimension coordinates:
          time                           x         -
     Auxiliary coordinates:
          latitude                       -         x
          longitude                      -         x

which causes the iris error:

  File "/home/users/ldemora/workspace/ESMValTool/ESMValCore/esmvalcore/cmor/check.py", line 643, in _check_coord_points
    self._cube = self._cube.intersection(lon_extent)
  File "/home/users/ldemora/miniconda3/envs/esmvaltool/lib/python3.9/site-packages/iris/cube.py", line 2864, in intersection
    result = result._intersect(*arg, ignore_bounds=ignore_bounds)
  File "/home/users/ldemora/miniconda3/envs/esmvaltool/lib/python3.9/site-packages/iris/cube.py", line 2884, in _intersect
    raise ValueError("expected 0 or 2 bound values per cell")

[zklaus]

I don't think the data is at fault here. AWI uses a triangulated mesh that has no straightforward mapping to a topologically rectangular storage, so every cell is on its own and needs to provide latitude and longitude. Unfortunately iris' intersection doesn't support this, which in turn means that you/we have to do without it or regrid the data prior to using intersection.

Is this a problem that appears in loading the data with no possibility for the user to intervene? If that is the case we have to look at the check perhaps. Compare with ESMValGroup/ESMValCore#751

[schlunma]

@bsolino this might be interesting for you. We found the same issue for ICON. I think the check needs to be fixed here in such a way that cube.intersection is not called for unstructured grids.

[bsolino]

Thanks @schlunma for letting me know!

This is what we did for ICON. Our solution was a bit radical, ignoring the check completely when the grid was unstructured: https://github.com/ESMValGroup/ESMValCore/pull/1079/files#diff-6172ad8f1681a8ee550de924c47765fcb59b77a8a8dd2e98ada108b144380ac7

It did the job for us, but I personally feel wary of ignoring a check that I don't really understand. What is the purpose of this test, and can it be ignored safely?

[ledm]

I don't think the data is at fault here. AWI uses a triangulated mesh that has no straightforward mapping to a topologically rectangular storage, so every cell is on its own and needs to provide latitude and longitude. Unfortunately iris' intersection doesn't support this, which in turn means that you/we have to do without it or regrid the data prior to using intersection.

I didn't know that any CMIP6 models used triangular grids! I suspect that the solution for me is to use the regridded gr data, if it exists!

[zklaus]

I think that is the most sensible thing to do right now. Maybe we can revisit this when our regridding has gained the ability to deal with it.

[schlunma]

With the option unstructured_nearest @bsolino and I managed to regrid ICON's unstructured grid to a regular grid as a first approximation with the current version of the core, so it might for AWI, too.