-
Notifications
You must be signed in to change notification settings - Fork 44
Refactor regridding #2231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor regridding #2231
Conversation
valeriupredoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey Manu, no actual changes needed, just a couple questions for now - the review block is more for me since I'm not done going through the code yet (just got to _regrid_esmpy
valeriupredoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a very nice unification PR, Manu, many thanks! I am very happy to see this happening, but I have a few concerns related to the way how things are structured ie private/public access to various classes and methods, and a bit of extra complexity that IMHO we can do without. Nothing major tho 🍺
| tgt_cube, | ||
| method=self._METHOD, | ||
| mask_threshold=self.mask_threshold, | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK call me old fashioned but to me this is a bit wrong: public method in a private class is something I don't agree with, especially since the ESMPYScheme name doesn't reflect the fact that an actual regridder instance is built within its bellows. What's wrong with the old generic and public regrid wrapper that the user is exposed to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you that this looks too complicated, but this is how iris expects regridding schemes to look like! The scheme class needs a public method regridder(self, src_cube, target_grid) that returns an object of a regridder class. This regridder class needs to have a method def __call__(self, cube) that actually performs the regridding. Here is an example for a regridder in iris.
The advantage of this new syntax is that it's much more generic. All of our regridding schemes are used the same way (within iris.cube.Cube.regrid(). In the old version, some schemes used the iris syntax, some use this regrid function that you mentiond, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed - I caught that, and liked it - but here's the thing - aligning ourselves to iris is not something we should aim for. If we find a nice, generic, and robust way of writing code and functionality we should go that way, regardless iris do other things; in this case, it's prob useful since we are in essence wrapping our regridding around iris regridding, so I'll grab the bait 🐟
| Regridder instance. | ||
| """ | ||
| return _GenericRegridder(src_cube, tgt_cube, self.func, **self.kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I see why the one above is private! OK - I'd argue you can coalesce that class into this one, and get rid of _GenericRegridder, and this is already public and does all the bits one needs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above about how iris implements regridders. This needs to stay like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mhmm, 🐟
valeriupredoi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approving this with very many thanks to Manu for the (rather heavy lifting) work, but I'd like a second pair of reviewing eyes, specifically @bouweandela or @zklaus please - Manu could you hold fire (merge, that is) until one of those two fellas have looked at it too, if you please, bud 🍺
bouweandela
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very nice improvement @schlunma!
A few comments:
- It would be nice to avoid leaking private things into the public API (check the API docs page)
- Could you please indicate in the API docs for each scheme if it supports lazy data?
|
Thanks for the review @bouweandela, I think I addressed all your comments 👍 |
| tgt_cube: | ||
| Cube defining the target grid. | ||
| method: | ||
| Regridding algorithm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to mention the valid method names here
bouweandela
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for these improvements @schlunma!
|
Thanks for the reviews @bouweandela and @valeriupredoi ! Merging this now since two people approved. |
|
yay 🥳 |
Description
This PR refactors our regridding. The main purpose is to simplify the code so that new schemes can be added more easily, which will be necessary for #2178.
Features
At the moment, the schemes
linear,area_weightedandnearestwork for regular and irregular grids. However, for unstructured grids, we have to useunstructured_nearest. This PR unifies this behavior so thatnearestcan also be used for unstructured grids (just like for irregular grids, I added a check for unstructured grids here that automatically selects the correct regridding scheme for unstructured grids).In addition, this PR unifies all regridding schemes so they can be used the (iris-intended) way within
Cube.regrid, just like the regridding schemes provided by iris. These are now located in the newesmvalcore.preprocessor.regridding_schemesmodule. With this, regridding is as easy asDeprecations
This PR deprecated two regridding schemes, which will be removed with ESMValCore v2.13.0:
unstructured_nearest: Please use the schemenearestinstead. This is an exact replacement for data on unstructured grids. ESMValCore is now able to determine the most suitable regridding scheme based on the input data.linear_extrapolate: Please use a generic scheme withreference: iris.analysis:Linearandextrapolation_mode: extrapolateinstead. This is an exact replacement, e.g.:Related to #2178
Link to documentation:
Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.
Changes are backward compatibleno: see deprecations aboveAll checks below this pull request were successfulRemaining Codacy checks aboutToo few public methods (1/2) (too-few-public-methods)cannot be fixed; it is necessary to use classes here due to the way iris regridding schemes are defined.To help with the number pull requests: