Esmf conserve

[pp-mo]

This is just a first attempt.
It adds an experimental routine to perform conservative regridding (i.e. preserving area sums).
It uses the ESMPy interface to the ESMF codebase ( See notes at www.earthsystemmodeling.org/ ).
It should work once you have installed ESMPy. I have a site-specific script for that, if you need it.
-- or see how it is done in '.travis.yml'

More importantly, what it does not yet do ..

• no support for curvilinear (2d) coordinates
• some known problems with odd testcases, which for now have known-failures coded into the tests (cf. test_global_collapse and test_single_cell)
• some other odd testing cases seemed to cause low-level ESMF errors. May need work to identify certain specific problem cases + raise more intelligible warnings

More testcases maybe needed :

• irregular grids

[esc24]

@pp-mo - Thanks for putting this up so people can get early visibility. Please add a sentence to the PR description that tells people what new functionality it provides.

[pp-mo]

@esc24 : Please add a sentence to the PR description that tells people what new functionality it provides.

Good point ! Done that now

[pp-mo]

Addressed some shortcomings, and attempt to add ESMPy/ESMF function to Travis
Should now be worth reviewing ;-)

NOTE: the current build failure is an existing problem, unrelated to the code changes

[rhattersley]

It's not the derived auxiliary coordinates that are regridded, it's their reference surfaces. And perhaps "linear interpolation" should be "bilinear interpolation" to reduce ambiguity.

[bblay]

==DO NOT MERGE==

Handy hint:
If you want to raise awareness through a pull request, you can submit one to your own master.
Then there is no risk of someone mistakenly merging it into the Iris master.

[pp-mo]

@bblay Handy hint:
If you want to raise awareness through a pull request, you can submit one to your own master.

Thanks, will do this in future.

[pp-mo]

==DO NOT MERGE==

Now removed: think we can now merge this (once "sufficiently fixed")

Thinking behind this:

• the added dependency (and new tests) are now optional, and removed from .travis.yml, so it doesn't make an unreasonable burden (before, it extended Travis testing time by about 8-9 minutes).
• the ESMF-dependent code tests still run in a test-all, if you have ESMPy installed.
• So as long as some people have it, it will get checked frequently + we will spot if something breaks it (just not for all PRs).

[bblay]

Do you plan on squashing this @pp-mo?

[pp-mo]

Small changes for comments - thanks @rhattersley.

Please re-examine.

[pp-mo]

@bblay Do you plan on squashing this @pp-mo?

May as well wait until we're closer to completion. I suspect there is a lot more to come.

[bblay]

Is it worth switching to the new api?
I assume this has already been discussed but I thought I'd ask.

There are currently two supported packages: ESMP and ESMPy. Both of these packages have the same general functionality. ESMP was a first prototype and ESMPy has a more Pythonic interface. After the ESMF_620 release (expected in May), the ESMP package will be deprecated and the ESMPy package will enter a beta phase.

[pp-mo]

See above.

[bblay]

the from_coords bit is not quite true : )