Handling xesmf dependency

[NoraLoose]

I'm currently working on refactoring the ROMS-Tools-internal regridding scheme, switching from xarray.interp to xesmf. The motivation for this is:

• predicted performance boost: xarray.interp does not re-use pre-computed weights, while xesmf does
• interpolation methods: xarray.interp only supports linear interpolation, while xesmf supports more sophisticated ones like bilinear and conservative

However, I'm wondering how we will handle the xesmf dependency. It looks like you can only install xesmf cleanly through conda but not through PyPi, see https://xesmf.readthedocs.io/en/stable/installation.html. The reason is that xesmf depends on ESMpy , which in turn is not available through PyPI.

Thoughts? cc @TomNicholas

[NoraLoose]

There is also still the outstanding question whether xesmf will break things if used together with dask.

[TomNicholas]

My understanding is that ESMF is a Fortran dependency, so by definition cannot be installed purely via pip (a python package manager). So if xesmf is a required dependency (not sure it needs to be) we may just have to only make CStar available via conda (which I think would be fine).

The dask vs ESMF problem is separable.

[NoraLoose]

Thanks!

So if xesmf is a required dependency (not sure it needs to be) we may just have to only make CStar available via conda (which I think would be fine).

It would have to be a required dependency if I refactor the regridding scheme to use xesmf. And just to clarify, we are talking about ROMS-Tools here, not C-Star. ;)

The dask vs ESMF problem is separable.

It is, but maybe not easily since weight generation and application of the weights need to happen upon the initialization of a class (e.g., SurfaceForcing).

[TomNicholas]

It would have to be a required dependency if I refactor the regridding scheme to use xesmf

But we could imagine xesmf being one amongst multiple options. Not sure if that's worth doing right now, but designing with that possibility in mind might be useful in the future.

It is, but maybe not easily since weight generation and application of the weights need to happen upon the initialization of a class (e.g., SurfaceForcing).

Can we change the API to separate out those two steps? e.g. generate weights upon class initialization and then .apply or something? It would be very useful to be able to do one then the other separately.