I'm not sure if this is a bug or a feature, to be honest. I noted that expanded scalar coordinates would retain their scalar values, and so thought that non-dimension coordinates might keep their references to each other and do the same.

What happened:

When a dimension is squeezed or selected with a scalar, the associated non-dimension coordinates are unassociated from the dimension. When the dimension is expanded later, the previously associated non-dimension coordinates are not expanded.

What you expected to happen:

The previously associated non-dimension coordinates should be expanded.

Minimal Complete Verifiable Example:

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

arr1 = xr.DataArray(np.zeros((1,5)), dims=['y', 'x'], coords={'e': ('y', [10])}) arr2 = arr1.squeeze('y').expand_dims('y')

xr.testing.assert_identical(arr1, arr2) ```

Error: ``` AssertionError: Left and right DataArray objects are not identical

Differing coordinates: L e (y) int64 10 R e int64 10 ```

Taken another way, I would desire these statements to be possible:

xr.DataArray(np.zeros(5), dims=['x'], coords={'y': 0, 'a': ('y', 1)}) xr.DataArray(np.zeros((0, 5)), dims=['y', 'x'], coords={'e': ('y', 10)})

Environment:

What happened:

Rechunking along an independent dimension causes unrelated non-dimension coordinates to become dask arrays. The dimension coordinates do not seem affected.

I can stick in a synchronous compute on the coordinate to recover, but wanted to be sure this was the expected behavior.

What you expected to happen:

Chunking along an unrelated dimension should not affect unrelated non-dimension coordinates.

Minimal Complete Verifiable Example:

```python import xarray as xr import dask.array as da

def print_coords(a, title): print() print(title) for dim in ['x', 'y', 'b']: if dim in a.dims or dim in a.coords: print('dim:', dim, 'type:', type(a.coords[dim].data))

arr = xr.DataArray(da.zeros((20, 20), chunks=10), dims=('x', 'y'), coords={'b': ('y', range(100,120)), 'x': range(20), 'y': range(20)})

print_coords(arr, 'Original')

The following line rechunks independently of b or y.

Removing this line allows the code to succeed.

arr = arr.chunk({'x': 5})

print_coords(arr, 'After chunking')

arr = arr.sel(y=2)

print_coords(arr, 'After selection')

print() print('Scalar values:') print('y=', arr.coords['y'].item()) print('b=', arr.coords['b'].item()) # Sad Panda Original dim: x type: <class 'numpy.ndarray'> dim: y type: <class 'numpy.ndarray'> dim: b type: <class 'numpy.ndarray'>

After chunking dim: x type: <class 'numpy.ndarray'> dim: y type: <class 'numpy.ndarray'> dim: b type: <class 'dask.array.core.Array'>

After selection dim: x type: <class 'numpy.ndarray'> dim: y type: <class 'numpy.ndarray'> dim: b type: <class 'dask.array.core.Array'>

Scalar values: y= 2

<stack trace elided> NotImplementedError: 'item' is not yet a valid method on dask arrays ```

Environment:

The behavior of stack was not quite intuitive to me, and I'd like to understand if this was an explicit technical decision or if it can be changed.

First, with regard to chunking: arr = xr.DataArray(da.zeros((2, 3, 4), dtype=np.int, chunks=(1 ,1, 1)), dims=['z', 'y' ,'x']) stacked = arr.stack(v=('y', 'x')) print(stacked) -- xarray.DataArray 'zeros-6eb2edd0fca7ec97141e1310bd303988' (z: 2, v: 12)> dask.array<reshape, shape=(2, 12), dtype=int64, chunksize=(1, 4), chunktype=numpy.ndarray> Coordinates: * v (v) MultiIndex - y (v) int64 0 0 0 0 1 1 1 1 2 2 2 2 - x (v) int64 0 1 2 3 0 1 2 3 0 1 2 3 Dimensions without coordinates: z

Why did the number of chunks change in this case? Couldn't the chunksize be (1,1)?

Next, why is it necessary to put the new dimension at the end? It seems there are often more natural (perhaps just to my naive thought process) placements. One example would be that same array above, but stacked on the first two dimensions. I would want the new dimension to be the first dimension (again without the rechunking above). To accomplish this, I do:

arr = xr.DataArray(da.zeros((2, 3, 4), dtype=np.int, chunks=(1 ,1, 1)), dims=['z', 'y' ,'x']) stacked = arr.stack(v=('z', 'y')).transpose('v', ...).chunk({'v': 1}) print(stacked) -- <xarray.DataArray 'zeros-6eb2edd0fca7ec97141e1310bd303988' (v: 6, x: 4)> dask.array<rechunk-merge, shape=(6, 4), dtype=int64, chunksize=(1, 1), chunktype=numpy.ndarray> Coordinates: * v (v) MultiIndex - z (v) int64 0 0 0 1 1 1 - y (v) int64 0 1 2 0 1 2 Dimensions without coordinates: x

The dask graph for this last bit insert a rechunk and two transposes, but my intent was not to have any of the underlying chunks change at all. Here is 1 of 8 pieces of the graph (with optimization off -- optimization combines operations, but doesn't change the topology or the operations):

Is it technically feasible for stack to avoid rechunking, and for the user to determine where the new dimensions should go?

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

Continuation of https://github.com/pydata/xarray/pull/5019, which closed during the master/main switch.

With an array containing a non-dimension coordinate, I do "where+squeeze" selection and can write the array to zarr without problem. However, if I write out and read back in the array prior to doing the selection, the array no longer writes properly.

The problem may stem from the non-dimension coordinate being read back as a dask array (which I can see by printing the coordinate).

The problem goes away if this line is altered to check for empty tuples in addition to None: if (var_chunks is None or not len(var_chunks)) and (enc_chunks is None or not len(enc_chunks)):

However, I'm not sure if the subtle change in the array will cause other issues, so I don't know if the above modification is a band-aid or a real solution.

MCVE Code Sample

```python

Your code here

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

def create(): image = da.zeros((2,2)) return xr.DataArray(image, dims=['y', 'x'], coords={'x': [0, 1], 'y': [0, 1], 'xname': ('x', ['apple', 'banana'])})

def select_and_write(arr, fname): arr = arr.where(arr.coords['xname'] == 'apple', drop=True) arr = arr.squeeze('x') arr.to_dataset(name='foo').to_zarr(fname, mode='w')

def ok(): print('ok') arr = create() select_and_write(arr, '/tmp/ok.zarr')

def error(): print('error') arr = create() arr.to_dataset(name='foo').to_zarr('/tmp/error_intermediate.zarr', mode='w') arr2 = xr.open_zarr('/tmp/error_intermediate.zarr')['foo'] select_and_write(arr2, '/tmp/error.zarr')

ok() error() ```

Expected Output

No stacktrace.

Problem Description

Versions

• [x] Closes #4084
• [x] Tests added
• [x] Passes pre-commit run --all-files

What happened:

When creating a dataset from two variables with a common dimension, there is a TypeError thrown when that dimension has shape nan.

What you expected to happen:

A dataset should be created. I believe dask has an allow_unknown_chunksizes parameter for cases like this -- would that be something that could work here? (Assuming I'm not making a mistake myself.)

Minimal Complete Verifiable Example:

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

def foo(): return np.zeros(3)

arr0 = da.from_delayed(dask.delayed(foo)(), shape=(np.nan,), dtype=float) arr0_xr = xr.DataArray(arr0, dims=('z',))

arr1 = da.from_delayed(dask.delayed(foo)(), shape=(np.nan,), dtype=float) arr1_xr = xr.DataArray(arr1, dims=('z',))

ds = xr.Dataset({'arr0': arr0_xr, 'arr1': arr0_xr}) ```

Anything else we need to know?:

Environment:

Is your feature request related to a problem? Please describe.

When using arrays with a nan shape, I'd like to provide a coordinate specification from a delayed object, which is my responsibility to make sure has the right chunks and length.

Describe the solution you'd like

Below are three examples that I think should work, where I give a coordinate via a dask array, a dask series, and a dask index. Currently, all three examples error out by computing the coordinate length (triggering an unwanted dask computation!), and then indicating that its different than the array's corresponding length, which is nan.

```python import dask import dask.array as da import dask.dataframe as dd import numpy as np import pandas as pd import xarray as xr

def foo(): return np.arange(4)

arr = da.from_delayed(dask.delayed(foo)(), shape=(np.nan,), dtype=int)

idx = da.from_delayed(dask.delayed(foo)(), shape=(np.nan,), dtype=int)

ddf = dd.from_pandas(pd.DataFrame({'y': np.arange(4)}), npartitions=1)

arr0 = xr.DataArray(arr, coords=[('z', idx)]) arr1 = xr.DataArray(arr, coords=[('z', ddf['y'])]) arr2 = xr.DataArray(arr, coords=[('z', ddf.index)]) ```

Error:

ValueError: conflicting sizes for dimension 'z': length nan on the data but length 4 on coordinate 'z'

Describe alternatives you've considered

After computations to complete add the missing coordinate. This requires carrying around the delayed index with the delayed array.

Names for dimensions are lost (renamed) when they are stacked and grouped, if one of the dimensions has string coordinates.

```python data = np.zeros((2,1,1)) dims = ['c', 'y', 'x']

d1 = xr.DataArray(data, dims=dims) g1 = d1.stack(f=['c', 'x']).groupby('f').first() print('Expected dim names:') print(g1.coords) print()

d2 = xr.DataArray(data, dims=dims, coords={'c': ['R', 'G']}) g2 = d2.stack(f=['c', 'x']).groupby('f').first() print('Unexpected dim names:') print(g2.coords) ```

Output

It is expected the 'f_level_0' and 'f_level_1' be 'c' and 'x', respectively in the second part below. ``` Expected dim names: Coordinates: * f (f) MultiIndex - c (f) int64 0 1 - x (f) int64 0 0

Unexpected dim names: Coordinates: * f (f) MultiIndex - f_level_0 (f) object 'G' 'R' - f_level_1 (f) int64 0 0 ```

Output of xr.show_versions()