I needed this functionality for a project, and piggy-backing off the last couple of comments decided the curve_fit wrapped by apply_ufunc approach works quite well. I put together a PR in #4849. Any feedback welcome!

cheers @TomNicholas , that's helpful. :) I've started messing with the idea in this Gist if you want to have a look.

It's pretty hacky at the moment, but might be helpful as a testbed. (And a way of getting my head around how apply_ufunc would work in this context)

@AndrewWilliams3142 I've tried to extend this to a 3d matrix (timeseries of 2d matrices) using Dask, it seems to work! Have a look here https://gist.github.com/clausmichele/8350e1f7f15e6828f29579914276de71

cheers @TomNicholas , that's helpful. :) I've started messing with the idea in this Gist if you want to have a look.

It's pretty hacky at the moment, but might be helpful as a testbed. (And a way of getting my head around how apply_ufunc would work in this context)

@AndrewWilliams3142 fair question: what I was envisaging was taking slices along that dimension(s), performing the curve fitting once for each slice (which should parallelize through apply_ufunc), then returning the optimised fitting parameters as a DataArray/Dataset which varied along that dimension. For example:

```python

2D dataarray of surface height with x & t dependence

height_data

def pulse_shape(x, peak_height, peak_location, FWHM): return peak_height * np.exp(-((x-peak_location)/FWHM)^2.0)

returned fit_params has t dependence

fit_params = height_data.fit(pulse_shape, fit_along='x')

Plot a graph of change in peak height over t

fit_params['peak_height'].plot(x='t') ```

@TomNicholas I'm a bit confused about how the fit_along argument would work actually. If you had 2D data and wanted to fit a 1D function to one of the dimensions, wouldn't you have to either take a mean (or slice?) across the other dimension?

Edit: It's been a hot day here, so apologies if this turns out to be a dumb q haha

+1 for just wrapping the existing functionality in SciPy for now. If we want a version of curve_fitthat supports dask, I would suggest implementingcurve_fit` with dask first, and then using that from xarray.

I am OK with using inspect from the standard library for determining default parameter names. inspect.signature is reasonably robust. But there should definitely be an optional argument for setting parameter names explicitly.

This sounds very cool! :) I'm not sure that I have much to add, but given @aulemahal 's good point about the complexity of rewriting curve_fit from scratch, it seems that maybe a good first step would just be to wrap the existing scipy functionality?

Alternatively, given that xr.apply_ufunc can already do this (though it's probably complicated), perhaps it would be good to just have an example in the documentation?

I am also trying to get similar results of scipy curve_fit with xarray and dask. Is there a workaround I can use to fit a sinusoidal function with the current functions/methods? This is the function I use to fit a seasonal trend with scipy: t = 365 def timeseries_function_season (x,a0,a1,a2): return a0+(a1*np.cos(2*np.pi/t*x)+a2*np.sin(2*np.pi/t*x)) timeseries_model_fit,pcov= curve_fit(timeseries_function_season,x,y)

My comments Q.1 : For now xr.apply_ufunc does not accept core dimensions to be chunked along, which would be kinda a sad for curve fitting. However, dask's least square method does, which is part of the reason why I used it in polyfit. On the other hand, scipy's least-squares procedure is not simple. Curve fitting is quite complex and rewriting all the code to use dask might be a project too ambitious, and surely out-of-scope for xarray...

Q.3 : For simple directly declared function, inspect does a good job, but it can get tricky with wrapped functions, which might arise in more complex workflows. Could we have a params arg that takes in a list of names?