Extend conservative regridding to additional dimensions (Previously: Add conservative interpolation scheme)

[stephenworsley]

✨ Feature Request

In the same way that AreaWeighted offers conservative regridding for horizontal coordinates, there should also be a scheme for conservative interpolation of non-horizontal coordinates. At the moment there is only a scheme for Linear and Nearest. A conservative scheme would require the altering of the existing pattern for interpolation since bounds are required for this calculation and not just points. We could consider adding bounds as a keyword argument to cube.interpolate(). It might also be worth considering the possibility of having target coordinates be an optional alternative argument to call interpolation with as a convenience.

Rather than providing conservative regridding via the interpolate method, it may make more sense to extend regridding directly by allowing regridding to work on non-horizontal coordinates.

Motivation

The way data is located on a cell, or the type of data it represents, can mean that different interpolation methods are more proper. If the data represents the measurement at a point then a linear method is likely to be more appropriate, but if it represents the average of some quantity between some bounds then a conservative method which uses these bounds may be more appropriate.

Additional context

Click to expand this section...

Please add additional verbose information in this section e.g., references, screenshots, listings etc

Tasks

Beta Give feedback

1. Proof of concept area weighted vertical regridding #6031
   Dragon Sub-Task 🦎 +1
2. Implement area weighted vertical regridding #6032
   Dragon Sub-Task 🦎 Status: Blocked +2

[pletzer]

Thanks @stephenworsley . This greatly captures the need to add conservative, length-weighted interpolation. Fields that require this are:

• Any cell-centred W3 fields (e.g. densities)
• Any W2h field, e.g. the u, v velocities in LFRic or UM.

[trexfeathers]

@pp-mo notes that anything involving bounds probably shouldn't be called 'interpolation'.

[trexfeathers]

@SciTools/iris-devs please comment with your most controversial opinions! Open season!

[zklaus]

Are you thinking 1D, e.g. different heights, full 3D, different 2D, e.g. transects, or something else entirely? Perhaps we can add one or two concrete examples with phenomenon, source grid, and target grid.

[stephenworsley]

@zklaus I was thinking of 1D interpolation though I could imagine there being a also case for 3D interpolation for something like altitude which varies over latitude/longitude. The example I had in mind was of a 1D height coordinate with bounds (representing other stagger points in an Arakawa grid). Interpolating from one height coordinate to another would involve each target point representing the interval between its bounds, the value at that point would be an average of all the values associated with source intervals which overlap with that target interval. This would be a weighted average based on the proportion of overlap.

Doing this with 3D coords would be more complicated and would require that the bounds were of shape (x, y, z, 2) and were specifically associated with the height dimension.

[bouweandela]

What are you planning in terms of computational performance? In the past, I've been advised by @bjlittle to avoid the Linear scheme because it is slow. It would be nice if any new scheme could be made in such a way that it is fast and supports lazy data (at least along cube dimensions that are not being interpolated) so we can actually use it with the ESMValTool.

[stephenworsley]

@bouweandela I'm in the process of improving the regridding code as part of #4754, you'll be pleased to learn I've already improved the performance of the PointInCell scheme in #4807 . One of the ideas here is to move towards a common backend for regridding with the same improved performance and lazy support. At any rate, we've learnt lessons about regridding performance which ought to carry over to any new regridders.

[pp-mo]

@SciTools/peloton @trexfeathers suggested that this has been seen as sort-of blocked by the above comment

[pp-mo]

@pp-mo my view is that there basically is no agreed, distinctive terminology to describe what "interpolation" + "regridding" should be and the difference/commonalities between them.

Specifically, I think that in Iris ...

• regridding means calculations which take account of cells + bounds (source + target),
• .. whereas interpolation refers only to calculations involving "values at points".
• Within Iris specifically, regrid + interpolate operate exclusively over horizontal coords -- but think this is not actually clearly stated anywhere (!)
• In Iris features, a "regridder" takes a target "grid_cube" + operates exclusively on coordinate information.
  Whereas, an "interpolator" has target (output) locations specified as a lists of point values (not a coordinate).

[ESadek-MO]

Step One: Proof of concept code
Step Two: API and Docstrings