Area statistics won't work on data with lambert Conformal projection

[thomascrocker]

For RCM data on a Lambert Conformal projection (see for example http://esg1.umr-cnrm.fr/thredds/fileServer/CORDEX_CNRM/output/EUR-11/CNRM/CNRM-CERFACS-CNRM-CM5/rcp85/r1i1p1/CNRM-ALADIN63/v2/3hr/tas/v20190419/tas_EUR-11_CNRM-CERFACS-CNRM-CM5_rcp85_r1i1p1_CNRM-ALADIN63_v2_3hr_200601010300-200701010000.nc ) the names of the x and y dim coordinates are projection_x_coordinate and projection_y_coordinate. I think this is a standard naming.

However, when dealing with irregular grids the code to calculate area statistics assumes that the names of these coordinates are grid_latitude and grid_longitude.

ESMValCore/esmvalcore/preprocessor/_area.py

Line 242 in 3078908

if 'grid_latitude' in coord_names and 'grid_longitude' in coord_names:

So the calculation of area weights fails.

This can probably be fairly easily fixed by modifying the logic on that line slightly. Creating this issue so it's on my TODO list of things to sort out re CORDEX. If I get around to creating a branch that fixes this I'll update this issue.

[zklaus]

@thomascrocker, I am afraid the issue is more subtle. The names grid_latitude and grid_longitude are reserved for only rotated regular grids. That is the only kind of grid for which we have the ability to calculate the areas, so merely changing the names doesn't help, we would need to add calculation of areas. That would be a great addition, preferably to iris, but it substantial effort.

[thomascrocker]

Ah yes, I see that the area_weights method only supports spherical co-ordinate systems.. In which case this makes it even more important that #865 and #184 are finished. This would at least allow me to regrid the data onto a regular grid as a workaround (and to be honest is needed for other purposes anyway).
What needs to be done to move them forward?

[zklaus]

I think #865 is essentially ready, we just got a bit side-tracked in the comments. #184 needs more work, I think. Either way, these will have to wait until after the 2.3.0 release.

[zklaus]

#865 is done, but #184 won't make it into this release, so I'll bump this issue to 2.5.0 as well. Sorry.

[thomascrocker]

#865 is done, but #184 won't make it into this release, so I'll bump this issue to 2.5.0 as well. Sorry.

No problem, #184 doesn't conflict with anything I need to do so I'm able still able to produce the analysis I need to.

[schlunma]

Moving this to v2.6 since there is not open PR yet.

[nhsavage]

a summary of where I think we are with this issue

1. we can't currently calculate area weights for data on lambert conformal grids because iris doesn't support this
2. we can't regrid to a regular lat/lon to allow us to bypass this issue until#184 is merged

So either:

1. we extend Iris to be able to calculate area weights (better, see iris:4812) or
2. we complete Add general CORDEX coordinate boundary fix #184 and work around the problem using regridding

Is that a good summary?

[zklaus]

@nhsavage, if we can get the areacella "fx" file, we should be able to read the area and make things work that way. Could you try an example with added cell area? The preprocessor section should look something like

preprocessors:
  my_preprocessor:
    area_statistics:
      operator: mean
      fx_variables:
        areacella:

[nhsavage]

we can give that a go, but in general that approach is sub optimal until #1082 is merged

[nhsavage]

also - the areacella files do not appear to be uploaded for the RegCM4 family of models. This is one of the CORDEX core models and as such is a key target here (we can ask for this to be uploaded of course)

[nhsavage]

Hmm. I have been drilling down into the source code where this fails. It seems that #999 actually added the support for using cell area files already. That suggests strongly that using the fx files is a good way forward. We should try this for the original file with a more recent release of ESMValCore.

That does add extra importance to #1082 though.

For the models which are misisng areacella files, we can use a twin track approach, asking the modellers to upload these files to ESGF and in the short term making our own files

[stephenworsley]

I've had a chat with @nhsavage, I believe that iris.analysis.cartography.area_weights can be approximated by using the back end of iris-esmf regrid using the following code:

import esmf_regrid

field = esmf_regrid.schemes._cube_to_GridInfo(cube).make_esmf_field()
field.get_area()
area_weights = field.data

Note: that this is probably going to be an approximation since ESMF assumes all straight lines are great circle arcs. If this turns out to be a workable solution, I could look into making this a pubic utility function in iris-esmf-regrid. Also, this seems to involve iris guessing the bounds since they were not present on the file I was experimenting with.

[bouweandela]

That does add extra importance to #1082 though.

@nhsavage An alternative approach has been implemented in the end, and has been available for a while now. See here for documentation.