issue_comments

Marking this as closed since the issue will be fixed in the next netcdf4-python release. Feel free to submit a PR with a work around for xarray if using the scipy backend is not a good alternative for you.

This is pretty clearly a netCDF4-Python bug, which I have reported upstream: https://github.com/Unidata/netcdf4-python/issues/743

If desired, we probably could pretty easily add a work around for this behavior (e.g., to create an empty numpy array of the appropriate shape) to our netCDF4-python wrapper: https://github.com/pydata/xarray/blob/9d09c1659741dafb1fadeed49c81f9e90a548b07/xarray/backends/netCDF4_.py#L50

This might be specific to string variables (character arrays) and netCDF4. My guess is that netCDF4 may not handle indexing on zero-dimensional arrays properly.

Reproduced also in my environment.

Selected repr of your dataset is python <xarray.Dataset> Dimensions: (N_CALIB: 1, N_HISTORY: 0, N_LEVELS: 1007, N_PARAM: 3, N_PROF: 33) Dimensions without coordinates: N_CALIB, N_HISTORY, N_LEVELS, N_PARAM, N_PROF Data variables: ... SCIENTIFIC_CALIB_DATE (N_PROF, N_CALIB, N_PARAM) object b'20150514141619' ... HISTORY_INSTITUTION (N_HISTORY, N_PROF) object ... It seems the data variable in concern, such as ds['HISTORY_STEP'], is 2-dimensional but one of the dimensions N_HISTORY is size 0.

~~Currently, xarray does not handle such zero-length n-dimensional arrays. Maybe we need to drop such variables when reading?~~

EDIT: This was wrong. xarray should handle 0-size nd-array.

@shoyer, @fmaussion, any idea?

I tried with xarray v0.9.6 but it raises the same error. Maybe also related to #1719 .

But is this really the issue? Because this works:

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

a = np.zeros((0, 2)) da = xr.DataArray(a) da.to_netcdf('test.nc')

xr.open_dataarray('test.nc') Out[16]: <xarray.DataArray (dim_0: 0, dim_1: 2)> array([], shape=(0, 2), dtype=float64) Dimensions without coordinates: dim_0, dim_1 ```

Currently, xarray does not handle such zero-length n-dimensional arrays. Maybe we need to drop such variables when reading?

Rather than drop a variable the user could read with no problem under xarray 0.9.6, I propose we examine our new indexing wrappers and figure out how to fix this bug.

~It's good to see that the release-candidate process actually works!~ 😭

It's good to see that the release-candidate process actually works! 😉

Yes, please upgrade to 0.10.0 and report back. I cannot reproduce your issue with this release version.

Guillaume--this is very troubling! I use xarray frequently on ARGO netCDF files. It would be a shame if we broke something related to reading them. It sounds like this could be related to the indexing changes in #1676.

Since rc1, xarray 0.10.0 has gone through another release candidate (rc2) and is now in full release. Can you try upgrading to the just-released 0.10.0 and verify whether the problem is still present?