How should multi-model statistics work on tas?

[zklaus]

More comprehensive metadata handling in the multi-model statistics recently turned up a conceptual issue for multi-model statistics on near-surface temperature (tas).

This variable is always "near-surface", but different models use slightly different heights, typically 2m or 1.5m.
It seems to be a consensus that a multi-model mean should just be calculated across all models, regardless of the exact height.

Open questions:

• Should the result always have :height=2m?
• Should all supported statistics (mean, median, max, min, std, and pXX.YY) be treated that way?
• Is tas a special case or is this in some way general/an issue for other variables as well?

Some aspects of this have been discussed in #1201 and #1198.

[katjaweigel]

A recipe, which is probably affected by this issue is recipe_flato13ipcc.yml (according to the list in ESMValGroup/ESMValTool#2198 it hasn't been tested for the new core, yet).

[alistairsellar]

To answer youir 3rd question @zklaus...
As far as I'm aware tas is the only CMIP variable which has this degree of flexibility in spatial metadata, so I think that tas is a special case when it comes to metadata.

There is a wider category of variables where you shouldn't make a multi-model mean because the variable has a different meaning for different models. Top level soil moisture (mrsos) is one, because models have different layer thicknesses and soil moisture can have a strong vertical gradient. Dust emission is another, because the algorithm / interpretation of "emission" differs so much between models. As Ruth kind of said just now, caveat usor.

[ruthlorenz]

I still do not know why they introduced the "height" for tas in CMIP6, it may be informative but not very helpful, just causing problems....
I would not have height=2m in the multi-model mean but drop it.
And I do not see there being a difference between how this should be handled for the different statistics, so I'd drop it in all cases.
For other variables I agree with Alistair.

[zklaus]

Ok, sounds like there should be a special case to ignore the scalar height dimension only for tas. @Peter9192, would you be willing to prepare a PR with such an addition for the multi-model statistics?

[schlunma]

One suggestion: Would it maybe make sense to add an optional keyword ignore_scalar_coordinates to multi_model_statistics? height is not the only scalar coordinate that is included in some variables (see here for various examples of fixes) and it might be useful to explicitly ignore these if desired.

The default value should be ignore_scalar_coordinates=False and the implementation would be rather simple:

if ignore_scalar_coordinates:
    for cube in cubes:
        for coord in cube.coords(dimensions=()):
            cube.remove_coord(coord)

[Peter9192]

I started with implementing a test in #1209 to establish the desired behaviour, but interestingly I find that iris already copes with this situation. It averages the coordinate value and sets bounds as well. Multi-model statistics pass just fine.

Does someone want to elaborate on a use case that failed for them?

[zklaus]

It seems that this was first diagnosed in #1198 (comment). @valeriupredoi, can you confirm that this is actually a problem?

Otherwise we'll close this issue sometime today.

[katjaweigel]

I'll test if it is still an issue on the modified version of recipe_pv_capacity_factor.yml, where @valeriupredoi saw it first and on a short version of recipe_flato13ipcc.yml only for the first figure, where it could play a role (it uses tas, a multi-model mean and ACCESS1-3 together with many other models).

[katjaweigel]

Fig 9.2 from recipe_flato13ipcc.yml runs, just produces the Warning:

209:WARNING [33549] /work/bd0854/b380216/anaconda3/envs/esmvaltool202106/lib/python3.9/site-packages/iris/coords.py:1979: UserWarning: Collapsing a non-contiguous coordinate. Metadata may not be fully descriptive for 'height'.
210: warnings.warn(msg.format(self.name()))

The same for the modified version of recipe_pv_capacity_factor.yml.
So this looks ok to me.

[Peter9192]

Thanks for checking @katjaweigel . That warning is harmless.

[zklaus]

Great, thanks @katjaweigel and @Peter9192 !

[schlunma]

Just out of curiosity: Were there any changes in the code or did this problem disappear by itself?

[zklaus]

As far as I can see there were no changes and this may never have been the problem, rather a similarity in error messages/warnings led to a misdiagnosis.

[katjaweigel]

Yes, it looks like for different heights for tas there was all the time only a warning, the recipe contained both, different heights for tas and different calendars, gave Warnings for both but failed due to the leap year issue.
Since several people said, averaging 2m and 1.5m tas should be ok, I guess for tas this is good like it is and needs no further changes. But it remains open, what happens with other variables (@alistairsellar mentioned mrsos), where averaging despite different metadata is not a good idea? Probably they are also averaged (with warning) as long as the number of points agree? But this should then probably be discussed in a new issue?

[Peter9192]

Do we still want to merge #1209? That PR adds a test to verify the behaviour discussed in this PR. It's currently in draft as I was waiting for more elaborate fail cases, but it seems there will be none

[zklaus]

@Peter9192, sounds good. Could you estimate when you have time for it, assign the 2.3.1 or 2.4.0 milestone accordingly, and wrap it up? I'll be happy to do the review.