support for additional scipy nd interpolants
- [x] Closes #7704
- [x] Adds support for n dimensional tensor product interpolants
slinear,cubic,quintic, andpchip. - [x] Updates documentation of DataArray/Dataset.interp and DataArray/Dataset.interp_like to reflect updates to scipy interpolants called.
- [x] Adds argument
reduceto allow disabling of reduction of interpolation along independent dimensions (see #2223). Prior to this the behavior was alwaysreduce=True. However for certain n-dimensional interpolants this will change the mathematical behavior of the interpolation (I think), so I have added an option for users to turn this off.
Outstanding uncertainty: dask/chunking behavior? Nothing about this PR touches the chunking of interpolation but I am a bit worried about this. Many interpolants, including those previously supported in one dimension, require nearby/all points from the original coordinate, and also don't parallelize well over the new coordinate. I'm not quite sure how this is currently being handled.
Thanks for this contribution.
Some remarks:
What is the minimal scipy version that is required for these new interpolators? Is it aligned with the minimum version for xarray or do we need some checks for that?
You have added several formatting changes to totally unrelated parts that make it more difficult to review then necessary. Please try to avoid that.
Doc build failed, have to check if random or related to your docstrings.
Thanks for the comments!
What is the minimal scipy version that is required for these new interpolators? Is it aligned with the minimum version for xarray or do we need some checks for that?
I'm seeing 1.11 in ci/requirements/min-all-deps.yml and these interpolants were added in 1.10 so I think we're good.
You have added several formatting changes to totally unrelated parts that make it more difficult to review then necessary. Please try to avoid that.
Oops, reverted, sorry!
Also, I think the name "reduce" is not very intuitive, but I fail to come up with an alternative. "decompose" seems weird out of context. Does anyone have a suggestion?
Also, I think the name "reduce" is not very intuitive, but I fail to come up with an alternative. "decompose" seems weird out of context. Does anyone have a suggestion?
Perhaps the _interp makes decompose_interp sound less weird? Separate or split also sound OK to me.
Many interpolants, including those previously supported in one dimension, require nearby/all points from the original coordinate, and also don't parallelize well over the new coordinate. I'm not quite sure how this is currently being handled.
I think we end up rechunking to a single in a very roundabout way. I don't think you need to be too concerned about it for this PR. It does need an overhaul though
Thanks @hollymandel this is looking quite close. I only have a few small refinement requests.
I think the failed test in ubuntu-latest py3.12 flaky is unrelated to this PR. I've rerun a few times and it keeps happening though, not sure how to move forward.
that issue should be fixed by #9709, so the merge appears to have fixed that issue here, as well.