Plotting across the prime meredian

[morobking]

Hi all

I'll trying to make a diagnostic that plots data crossing the prime meridian (0 degrees east/west).
However I get plots looking like the attached, where to the east of zero degrees, something isnt right.
I can't find if this is an issue with iris plotting, or if the preprocessor which extracts a region from my datasets is causing the issue.
This problem is the same if I try to extract, say longitude -10 to +10 or 350 to 370 degrees,

I can see my obs data has longitude -180 to +180, and the CMIP6 model data I'm using has longitude 0-360. Is this a problem? If so I assume I need to re-run my obs data cmorizer with some code to correct the obs to 0-360 degrees?

My cmorizer, recipe and diagnostic are on the branch cmug_wp4_10

[zklaus]

This should be handled by the preprocessor. Could you provide the recipe that you are using so we can check how the preprocessor is used and what it does? I see that you mention the branch, but it would be easier to find things if you also add the name of the recipe that you are using. If you already have a PR, that would be equally good; if not, perhaps consider opening a draft PR for this branch.

[morobking]

@zklaus Thanks for looking at this - sorry I've been away from the office for a few days.
The recipe is esmvaltool/recipes/recipe_cmug_wp4_10.yml

[morobking]

Does anyone have thoughts on this please?

[zklaus]

@bouweandela, it's slightly more nuanced, and I would say the tables are wrong here since they run counter to the official guidance, where on page 6, note 9 it says:

[...] For the auxiliary coordinate case considered here (when the longitudes and latitudes are pointed to by the “coordinates” attribute), it is recommended that when possible, longitudes increase monotonically and be confined to the range -180 to 360 (with their span limited to a single cycle), but this is not a requirement of CF or of CMIP6. In particular, it would usually be better to avoid jumps in adjacent longitudes (e.g., from 359.5 to 0.5) by adding or subtracting 360 (e.g., if adjacent longitudes were 359.5 and 0.5, they might be redefined as -0.5 and 0.5).

Now, that is for multidimensional coordinates, but simple CF conventions terminology already tells us that coordinate variables must be numerical and monotonically increasing, so if the data is present from -180 to 180 degrees, it would be even worse to just change the coordinate to wrap around and go 180, 181, ..., 360, 1, 2, 3, ..., 179.

[zklaus]

@bouweandela, what is https://github.com/ESMValGroup/ESMValCore/blob/23eb7c8069d4c895c90927e4f1429b250cdb8a9d/esmvalcore/preprocessor/_area.py#L71 doing? That looks like a bug to me.

[bouweandela]

@zklaus We have similar code to 'correct' this already as part of the automatic fixes here: https://github.com/ESMValGroup/ESMValCore/blob/ead491ab8b3325fa1f88b9fa6aad7cfc0d050e77/esmvalcore/cmor/check.py#L710.

Correct or not, I believe that some preprocessor functions depend on this and diagnostics might also depend on this.

[bouweandela]

coordinate variables must be .. monotonically increasing,

I've thought about this a bit more and to be honest, I think that periodic coordinates cannot be monitonically increasing. Looking at the definition of monotonically increasing on Wikipedia seems to confirm that.

[zklaus]

Could you elaborate? It seems perfectly consistent to me. Of course, we must keep in mind the three parts that make up a function $f: X \to Y$, the mapping, the domain, and the codomain. For a longitude coordinate variable, the domain would be the integer range that indexes the variable, the codomain would be a continuous subset of [-180, 360] and the mapping is usually affine.

[morobking]

Thanks for keeping looking at this.
So this is an issue with ESMValTool's preprocessor, not an issue with how I'm using Iris in the diagnostic?

[bouweandela]

It could also be an issue with the plotting function you're using. I would expect cartographic plotting functions to understand about periodic lat/lon coordinates.

[pepcos]

I've had this issue in the past but just when plotting with pcolormesh(). I believe contourf() works fine. My guess is that the jump from longitude~40º to longitude~355º messes things up with the pcolormesh function.

The way I dealt with it was to interpolate the data to longitudes going from -180 to 180 in my diagnostic. Here is the example

ESMValTool/esmvaltool/diag_scripts/cos22esd/hotspot_plotter.py

Line 699 in e023284

def regrid_longitude_coord(self, cube):

[bouweandela]

Could it be that this is a bug in the iris pcolormesh function?

I believe you can do something similar to what you are doing without interpolation by using code like this (but with -180, 180 instead of 0, 360):
https://github.com/ESMValGroup/ESMValCore/blob/ead491ab8b3325fa1f88b9fa6aad7cfc0d050e77/esmvalcore/cmor/check.py#L749-L751

[pepcos]

Could it be that this is a bug in the iris pcolormesh function?

I think so, there is no comment on how the coordinates should increase or decrease in the documentation. Maybe the issue should be raised in Iris, or even matplotlib?

I believe you can do something similar to what you are doing without interpolation by using code like this (but with -180, 180 instead of 0, 360):
https://github.com/ESMValGroup/ESMValCore/blob/ead491ab8b3325fa1f88b9fa6aad7cfc0d050e77/esmvalcore/cmor/check.py#L749-L751

Indeed, the solution you propose is much cleaner! Thanks, I didn't know about it. It would change the previous code I sent to:

    def regrid_longitude_coord(self, cube):
        """Sorts the longitudes of the cubes from 0/360 degrees to -180/180"""
        coord = cube.coord("longitude")
        lon_extent = iris.coords.CoordExtent(coord, -180., 180., True, False)
        cube = cube.intersection(lon_extent)
        return cube

[bouweandela]

Maybe the issue should be raised in Iris, or even matplotlib?

It would be great if you could open an issue in iris about this because pcolormesh is an iris function. If it needs to be raised somewhere else (e.g. cartopy), the iris developers will probably know.

[zklaus]

I don't think this is a problem in Iris (perhaps that it should warn about the erroneous coordinates). The documentation states that DimCoords must be monotonic (see here).