Contradiction between longitude checks for CORDEX

[aulemahal]

[issue copied from cc-plugin-cc6]

I think there's an issue in the longitude check because two checks are contradicting when applied to the AUS domain which crosses the 180/-180 line. (See image in https://github.com/WCRP-CORDEX/domain-tables/).

I am referring to check CDXV003.

• If longitude values are [0, 360], this fails with : Longitude values are required to take the smallest absolute value in the range [-180, 360], as any values east of 180° could be negative instead.
• If longitude values are [-180, 180], this fails with: The longitude coordinate should be strictly monotonically increasing., as there a leap from 180 to -180 in the middle.

Moreover, the current cmor tables seem to define the valid range as [0, 360].
https://github.com/WCRP-CORDEX/cordex-cmip6-cmor-tables/blob/50af478ebb019d9358b1c87d02236150b06fb3b0/Tables/CORDEX-CMIP6_coordinate.json#L225-L226

My guess is that the CMOR definition is inherited from GCMs and the test implemented in cc-plugins-cc6 and here did not take all domains into account.

I would argue that in this case, the [0, 360] range is much more appropriate, and the other check could be ignored. However, even with this change, the ARC and ANT domains wouldn't be able to respect the "monotonicaly increasing" condition. Does this mean we should have exceptions for those, or that the full check should have a lower severity ?

As a side note, I am not managing any AUS data. I stumbled on this problem with NAM data, but our actual domain crosses the antimeridian somewhere in Russia.

[sol1105]

@aulemahal Thanks for reporting this. Indeed when setting this up (attempting to follow the archive specifications), I was relying only on EUR-12 CORDEX-CMIP6 data. I will look into this, using also CORDEX-CMIP5 data for other domains (I do not have any CORDEX-CMIP6 testdata available for other than the EUR domain).

I'll have a close look at the archive specs again, and at my implementation, and will see where above contradiction originates from. I would guess that the archive specifications in that regard try to prevent such jumps at the 0/anti-meridian (-180 to 180 or 360 to 0) but that my implementation and/or the formulation is just working for EUR and possibly some others, like AFR.

[aulemahal]

Thanks!

If you want some NAM-12 examples, we have some here : https://pavics.ouranos.ca/twitcher/ows/proxy/thredds/catalog/birdhouse/disk2/ouranos/CORDEX/CMIP6/DD/NAM-12/OURANOS/catalog.html

The version is almost compliant with the specs, but not quite. I am in the process of making a second version ready for ESGF publication, which is how I stumbled on this issue. You'll note that our domain is larger than the CORDEX-defined one. I'm not sure how problematic this is compliance-wise, but we'll want to publish the full version to ESGF, which means a domain crossing the anti-meridian.

[sol1105]

@aulemahal I had a look at the archive specs, and indeed the implementation does not respect that the longitude values as small as possible requirement is only secondary to the monotonicity and -180..360 requirements:

The 2-dimensional geographic latitudes and longitudes of the model grid cells (lon and lat) must be also provided as auxiliary coordinates. Longitude coordinates must be strictly monotonically increasing and confined to the range -180 to 360; they must also have absolute values as small as possible given the first two constraints (e.g., store 170 E to 170 W as 170 to 190, but store 150 W to 130 W as -150 to -130, not 210 to 230).

So the implemented logic should be:

• Are the values monotonically increasing?
• Are the values defined in the -180, 360 interval? (the CMOR tables may have to be corrected to match the archive specifications in that point)
• If defined on the 0..360 interval, will converting to -180..180 conflict with the monotonicity requirement?

I will work on that.

For your data that would mean:
Defining it on the range 175 .. 180 -> -180 .. -5 would conflict with the monotonicity requirement, although respecting the smallest value requirement, which however is less important. So the longitudes would have to be converted to 175..355 instead, to comply with the archive specifications.

Apart from that there is one more incorrect issue reported (by the cc6 checker in cc-plugin-cc6 only, as this check did not make it (yet) to cc-plugin-wcrp):

Present variables

• (Coordinate) variable(s) quantization_info is/are not part of the CV or not compliant with the CF-Conventions.

This error should not pop up. Generally, extra variables should not be allowed, but in this case it is of course correct to specify quantization_info if any lossy compression was applied.

The other raised issues/recommendations seem correct.

Please note: integrating the cordex-cmip6 checks from the cc-plugin-cc6 in this plugin is ongoing work and currently you should probably use both available cordex-cmip6 checkers (the "old" on in cc-plugin-cc6 and the new one in cc-plugin-wcrp), until the checker is completely integrated in cc-plugin-wcrp. Also, the cf checker should be run as well: -t cf:1.11. So the full checker call could look as follows:

cchecker.py -t cf:1.11 -t cc6 -t wcrp_cordex_cmip6 -O "wcrp_cordex_cmip6:force_table_download:true" -O "cc6:force_table_download:true" /path/to/file_to_be_checked.nc

(with occasionally activating the table download, so you do not check against outdated tables)

[aulemahal]

Thanks for all this info!

I agree with putting monotonicity at a higher priority. I'll adapt my cmorization to use the 175-360 range.

However, I still note that "monotonically increasing" is still impossible for the ARC and ANT domains. You'll always have a ±360 jump somewhere in the domain as a straight line from the center (pole) to the edge. Example here for Arctic with the 0-360 range:

[sol1105]

Thank you, yes, the check needs to be modified to not raise an error for these domains, and probably the arch. specs. should be updated with some guidance for these domains as well.

[sethmcg]

Hey, I just ran into this same issue on some different NAM simulations. Thanks for addressing it!

I think the "monotonic" rule is kind of confusing, especially in the polar context. I'm on the TTPI for CORDEX-CMIP7, and we could change things for the next round of CORDEX. Would it be clearer if we expressed these rules this way instead?

• Longitudes must be in the range [-180, 360]
• If the domain contains a pole OR if it spans neither 0 longitude nor 180 longitude, its longitudes should be <= 180
• Otherwise:
  • If the domain spans 0 longitude, its westernmost longitude should be < 0
  • If the domain spans 180 longitude, its easternmost longitude should be > 180

I believe that accounts for the case where the domain crosses two meridians, doesn't require defining and testing for monotonicity, and is domain-neutral (i.e., doesn't depend on having a named domain to exempt from the rules, though you could use "is ARC or ANT" as a shortcut for testing whether the domain contains a pole.)