You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that this only happens when a dask.distributed client is loaded
What you expected to happen: expected it to return the same slice it does without error if the client is not active.
Minimal Complete Verifiable Example: I tried really really hard to create a synthetic example but I couldn't make one that
would fail, but loading the mfdataset from disk will make it fail reliably. I have tested multiple times.
@aidanheerdegen thanks for the report. Are you sure that you are using cftime version 1.5.0? It is surprising to me that the dates are decoded to cftime.datetime objects and not cftime.DatetimeNoLeap objects. I suspect this is where the problem stems from -- currently xarray does not support the universal base class (#4853).
Eventually the goal is to deprecate the calendar-specific subclasses like cftime.DatetimeNoLeap. For a brief moment -- cftime version 1.4.0 -- the universal class was the default type returned by cftime.num2date, but this proved to be premature, because it broke a significant amount of downstream functionality. More recent versions -- 1.4.1 and later -- have rolled back to returning the subclasses by default. By any chance are you actually using version 1.4.0?
What happened: Tried to
.sel()
a time slice from a multi-file dataset whendask.distributed
client active. Got this error:So the slice indexing has created a bounding value with the wrong calendar, should be
365_year
but isgregorian
.Note that this only happens when a
dask.distributed
client is loadedWhat you expected to happen: expected it to return the same slice it does without error if the client is not active.
Minimal Complete Verifiable Example: I tried really really hard to create a synthetic example but I couldn't make one that
would fail, but loading the
mfdataset
from disk will make it fail reliably. I have tested multiple times.The dataset:
Anything else we need to know?: I tried following the code execution through with
pdb
and it seems to start going wrong herexarray/xarray/core/indexing.py
Line 55 in eea7673
by line 63
data_obj.xindexes
is already in a bad statexarray/xarray/core/indexing.py
Line 63 in eea7673
It is called here
xarray/xarray/core/indexing.py
Lines 106 to 108 in eea7673
but it isn't obvious to me how that bad state is generated.
Environment:
Output of xr.show_versions()
INSTALLED VERSIONS
commit: None
python: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:39:48)
[GCC 9.3.0]
python-bits: 64
OS: Linux
OS-release: 4.18.0-326.el8.x86_64
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: en_AU.utf8
LANG: en_US.UTF-8
LOCALE: ('en_AU', 'UTF-8')
libhdf5: 1.10.6
libnetcdf: 4.7.4
xarray: 0.19.0
pandas: 1.3.1
numpy: 1.21.1
scipy: 1.7.0
netCDF4: 1.5.6
pydap: installed
h5netcdf: 0.11.0
h5py: 2.10.0
Nio: None
zarr: 2.8.3
cftime: 1.5.0
nc_time_axis: 1.3.1
PseudoNetCDF: None
rasterio: 1.2.6
cfgrib: 0.9.9.0
iris: 3.0.4
bottleneck: 1.3.2
dask: 2021.07.2
distributed: 2021.07.2
matplotlib: 3.4.2
cartopy: 0.19.0.post1
seaborn: 0.11.1
numbagg: None
pint: 0.17
setuptools: 52.0.0.post20210125
pip: 21.1.3
conda: 4.10.3
pytest: 6.2.4
IPython: 7.26.0
sphinx: 4.1.2
The text was updated successfully, but these errors were encountered: