What happened?

I receive unnecessary warnings when opening Zarr datasets with empty dimensions/arrays using the chunks argument (for a non-empty dimension).

If an array has zero size (due to an empty dimension), it is saved as a single chunk regardless of Dask chunking on other dimensions (#5742). If the chunks parameter is provided for other dimensions when loading the Zarr file (based on the expected chunksizes were the array nonempty), xarray gives a warning about potentially degraded performance from splitting the single chunk.

What did you expect to happen?

I expect no warning to be raised when there is no data:

• performance degradation on an empty array should be negligible.
• we don't always know if one of the dimensions is empty until loading. But we would use the chunks parameter for dimensions with consistent chunksizes (to specify a multiple of what's on disk) -- this is thrown off when other dimensions are empty.

Minimal Complete Verifiable Example

```Python import xarray as xr import numpy as np

each a is expected to be chunked separately

ds = xr.Dataset({"x": (("a", "b"), np.empty((4, 0)))}).chunk({"a": 1})

but when we save it, it gets saved as a single chunk

ds.to_zarr("tmp.zarr")

so if we open it up with expected chunksizes (not knowing that b is empty):

ds2 = xr.open_zarr("tmp.zarr", chunks={"a": 1})

we get a warning :(

```

Relevant log output

Python {...}/miniconda3/envs/new-majiq/lib/python3.8/site-packages/xarray/core/dataset.py:410: UserWarning: Specified Dask chunks (1, 1, 1, 1) would separate on disks chunk shape 4 for dime nsion a. This could degrade performance. (chunks = {'a': (1, 1, 1, 1), 'b': (0,)}, preferred_ch unks = {'a': 4, 'b': 1}). Consider rechunking after loading instead. _check_chunks_compatibility(var, output_chunks, preferred_chunks)

Anything else we need to know?

This can be fixed by only calling _check_chunks_compatibility() whenever var is nonempty (PR forthcoming).

Environment

INSTALLED VERSIONS [3/1946]

commit: None python: 3.8.12 | packaged by conda-forge | (default, Jan 30 2022, 23:42:07) [GCC 9.4.0] python-bits: 64 OS: Linux OS-release: 5.4.72-microsoft-standard-WSL2 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: C.UTF-8 LOCALE: ('en_US', 'UTF-8') libhdf5: 1.12.1 libnetcdf: None

xarray: 2022.3.0 pandas: 1.4.1 numpy: 1.22.2 scipy: 1.8.0 netCDF4: None pydap: None h5netcdf: None h5py: 3.6.0 Nio: None zarr: 2.11.1 cftime: 1.5.1.1 nc_time_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.4 dask: 2022.01.0 distributed: 2022.01.0 matplotlib: 3.5.1 cartopy: None seaborn: 0.11.2 numbagg: None fsspec: 2022.01.0 cupy: None pint: None sparse: None setuptools: 59.8.0 pip: 22.0.4 conda: None pytest: 7.0.1 IPython: 8.1.1 sphinx: 4.4.0

What happened: On a device with no display available, importing xarray without setting the matplotlib backend hangs on import of matplotlib.pyplot since #5794 was merged.

What you expected to happen: I expect to be able to run import xarray without needing to mess with environment variables or import matplotlib and change the default backend.

What happened: Following guidance on how to use regions keyword in xr.Dataset.to_zarr(), I wrote a multithreaded program that makes independent writes to each index along an axis. But, when I use more than one thread, some of these writes fail.

What you expected to happen: I expect all the writes to take place safely so long as the regions I write to do not overlap (they do not).

Minimal Complete Verifiable Example:

```python path = "tmp.zarr" NTHREADS = 4 # when 1, things work as expected import multiprocessing.dummy as mp # threads, instead of processes

import numpy as np import dask.array as da import xarray as xr

dummy values for metadata

xr.Dataset( {"x": (("a", "b"), -da.ones((10, 7), chunks=(None, 1)))}, {"apple": ("a", -da.ones(10, dtype=int, chunks=(1,)))}, ).to_zarr(path, mode="w", compute=False)

actual values to save

ds = xr.Dataset( {"x": (("a", "b"), np.random.uniform(size=(10, 7)))}, {"apple": ("a", np.arange(10))}, )

save them using NTHREADS

with mp.Pool(NTHREADS) as p: p.map( lambda idx: ds.isel(a=slice(idx, 1 + idx)).to_zarr(path, mode="r+", region=dict(a=slice(idx, 1 + idx))), range(10) ) ds_roundtrip = xr.open_zarr(path).load() # open what we just saved over multiple threads

perfect match for x on some slices of a, but when NTHREADS > 1, x has very different value or NaN on other slices of a

xr.testing.assert_allclose(ds, ds_roundtrip) # fails when NTHREADS > 1. ```

Anything else we need to know?:

• this behavior is the same if coordinate "apple" (over a) is changed to be coordinate "a" (index over dimension)
• if dummy dataset had "apple" defined using dask, I observed ds_roundtrip having all correct values of "apple" (but not "x"). But, if it was defined as a numpy array, I observed ds_roundtrip having incorrect values of "apple" (in addition to "x").

Environment:

What happened: I have an xr.Dataset with a dask-array-valued variable including zero-length dimension (other variables are non-empty). I tried saving it to zarr, but it fails with a zero division error.

What you expected to happen: I expect it to save without any errors.

Minimal Complete Verifiable Example: the following commands fail.

```python import numpy as np import xarray as xr

ds = xr.Dataset( {"x": (("a", "b", "c"), np.empty((75, 0, 30))), "y": (("a", "c"), np.random.normal(size=(75, 30)))}, {"a": np.arange(75), "b": [], "c": np.arange(30)}, ).chunk({})

ds.to_zarr("fails.zarr") # RAISES ZeroDivisionError ```

Anything else we need to know?: If we load all the empty arrays to numpy, it is able to save correctly. That is:

python ds["x"].load() # run on all variables that have a zero dimension ds.to_zarr("works.zarr") # successfully runs

I'll make a PR using this solution, but not sure if this is a deeper bug that should be fixed in zarr or in a nicer way.

Environment:

MCVE Code Sample

```python import xarray as xr

create data array with named dimension and named coordinate

x = xr.DataArray([1], {"idx": [2], "y": ("idx", [3])}, ["idx"], name="x")

what's our current index? (idx, this is fine)

x.indexes

prints "idx: Int64Index([2], dtype='int64', name='idx')"

swap dim so that y is our dimension, what's index now?

x.swap_dims({"idx": "y"}).indexes

prints "y: Int64Index([3], dtype='int64', name='idx')"

``` The dimension name is appropriately swapped but the pandas index name is incorrect.

Expected Output

```python

swap dim so that y is our dimension, what's index now?

x.swap_dims({"idx": "y"}).indexes

prints "y: Int64Index([3], dtype='int64', name='y')"

```

Problem Description

This is a problem because running x.swap_dims({"idx": "y"}).to_dataframe() gives a dataframe with columns ["x", "idx"] and index "idx". This gives ambiguous names and drops the original name, while the DataArray string representation gives no indication that this might be happening.

Output of xr.show_versions()