• [x] Closes https://github.com/xarray-contrib/xeofs/issues/148
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The change from https://github.com/pydata/xarray/pull/8672 mostly fixed the issue of serializing a reset multiindex in the backends, but there was an additional niche issue that turned up in xeofs that was causing serialization to still fail on the zarr backend.

The issue is that zarr is the only backend that uses a custom version of encode_cf_variable called encode_zarr_variable, and the way this gets called we don't pass through the name of the variable before running ensure_not_multiindex.

As a minimal fix, this PR just passes name through as an additional arg to the general encode_variable function. See @benbovy's comment that maybe we should actually unwrap the level coordinate in reset_index and clean up the checks in ensure_not_multiindex, but I wasn't able to get that working easily.

The exact workflow this turned up in involves DataTree and looks like this: ```python import numpy as np import xarray as xr from datatree import DataTree

ND DataArray that gets stacked along a multiindex

da = xr.DataArray(np.ones((3, 3)), coords={"dim1": [1, 2, 3], "dim2": [4, 5, 6]}) da = da.stack(feature=["dim1", "dim2"])

Extract just the stacked coordinates for saving in a dataset

ds = xr.Dataset(data_vars={"feature": da.feature})

Reset the multiindex, which should make things serializable

ds = ds.reset_index("feature") dt1 = DataTree() dt2 = DataTree(name="feature", data=ds) dt1["foo"] = dt2

Somehow in this step, dt1.foo.feature.dim1.variable becomes an IndexVariable again

print(type(dt1.foo.feature.dim1.variable))

Works

dt1.to_netcdf("test.nc", mode="w")

Fails

dt1.to_zarr("test.zarr", mode="w") ```

But we can reproduce in xarray with the test added here.

• [x] Closes #7702, #8421
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

A quick pass at implementing these two improvements for zarr region writes:

1. allow passing region={dim: "auto"}, which opens the existing zarr store and identifies the correct slice to write to, using a variation of the approach suggested by @DahnJ here. We also check for non-matching coordinates and non-contiguous indices.
2. automatically transpose dimensions if they otherwise match the existing store but are out of order

• [x] Closes #7362
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

• [x] Closes #7220
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Reverts the getattr method used in xr.where(..., keep_attrs=True) from #6461, but keeps handling for scalar inputs. Adds some test cases to ensure consistent attribute handling.

• [x] Closes #6444
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Fixes a bug introduced by #4687 where passing a non-xarray object to x in xr.where(cond, x, y, keep_attrs=True) caused a failure. The keep_attrs callable passed to merge_attrs() tries to access the attributes of x which do not exist in this case. This fix just checks to make sure x has attributes, and if not will pass through keep_attrs=True.

• [x] Closes #7062
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

This just tests to make sure we at least get the same dtype whether we have a numpy or dask array.

• [x] Closes #6484
• [x] Tests added

I've often been tripped up by the stack trace noted in #6484. This PR changes two things:

1. Handles the zarr GroupNotFoundError error with a more informative FileNotFoundError, displaying the path where we didn't find a zarr store.
2. Moves the consolidated metadata warning to after the step of successfully opening the zarr with non-consolidated metadata. This way the warning isn't shown if we are actually trying to open a non-existent zarr store, in which case we only get the error above and no warning.

• [x] Closes #4300
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

This is a simple implementation of a more general curve-fitting API as discussed in #4300, using the existing scipy curve_fit functionality wrapped with apply_ufunc. It works for arbitrary user-supplied 1D functions that ingest numpy arrays. Formatting and nomenclature of the outputs was largely copied from .polyfit, but could probably be improved.