Repository navigation
Cannot read Zarr v2 data from SWIFT without consolidated metadata #10569
Description
What happened?
I'm trying to work with Zarr v2 data on a SWIFT store, with a fresh install of xarray and zarr in a virtual environment.
pip install swiftspec xarray "zarr[remote]"
If I open a dataset (which has been tested and used previously) without using the consolidated metadata, no variables are found:
import xarray as xr
botany_url="https://swift.dkrz.de/v1/dkrz_b42c6bc6-439f-4efb-9491-db3de70ad9ba/botany_1536_2D/botany_1536_2D.zarr"
ds_2D = xr.open_zarr(botany_url,consolidated=False)
print(ds_2D)
Changing to consolidated=True shows the variables. The dataset can be browsed here.
A possibly related issue:
When writing a Zarr v2 dataset to a SWIFT store, the consolidated metadata is written correctly if the dimension separator is the default, ., but not if it is changed to /. This means a v2 dataset with separator / written to SWIFT cannot be read back. This may be specific to SWIFT or more broadly to fsspec stores - writing to a local directory with a zarr.storage.DirectoryStore does write the consolidated metadata correctly (but this was tested with zarr 2.18.7 because in zarr 3 the DirectoryStore is gone).
Third issue: how do I write a Zarr v2 dataset with dimension_separator='/' using the current versions of everything, including zarr v3.x?
What did you expect to happen?
I expect to be able to read Zarr v2 from a SWIFT store with or without consolidated metadata.
I expect to be able to write Zarr v2 with dimension_separator='/' using the current versions of all the modules.
Minimal Complete Verifiable Example
import xarray as xr
botany_url="https://swift.dkrz.de/v1/dkrz_b42c6bc6-439f-4efb-9491-db3de70ad9ba/botany_1536_2D/botany_1536_2D.zarr"
ds_2D = xr.open_zarr(botany_url,consolidated=False)
print(ds_2D)MVCE confirmation
- Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
- Complete example — the example is self-contained, including all data and the text of any traceback.
- Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
- New issue — a search of GitHub Issues suggests this is not a duplicate.
- Recent environment — the issue occurs with the latest version of xarray and its dependencies.
Relevant log output
Anything else we need to know?
No response
Environment
Details
INSTALLED VERSIONS
commit: None
python: 3.12.3 (main, Jun 18 2025, 17:59:45) [GCC 13.3.0]
python-bits: 64
OS: Linux
OS-release: 6.8.0-63-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: None
libnetcdf: None
xarray: 2025.7.1
pandas: 2.3.1
numpy: 2.3.2
scipy: None
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
zarr: 3.1.0
cftime: None
nc_time_axis: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: 2025.7.0
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: None
pip: 24.0
conda: None
pytest: None
mypy: None
IPython: None
sphinx: None
Activity
observingClouds commentedon Aug 1, 2025
Hi @fjansson,
Thanks for reporting this. The issue is unrelated to SWIFT as you access the zarr-store here via the
httpsprotocol (you do not need the swiftspec dependency). File listings in the https protocol probably do not exists, e.g. one can only request urls/chunks/variables that are known beforehand. Once a consolidated file exists (which is at the standard locationurl/.zmetadata) all variables (and their urls) can be inferred and loaded.fjansson commentedon Aug 1, 2025
@observingClouds You're right, even my example above used https://. The missing file listing operation makes sense, and that would explain why a similar read from a local folder worked.
Does this mean that consolidated metadata is necessary to access zarr over https? That would mean that it's currently not possible to write valid zarr v2 with dimension_separator='/' to SWIFT, because the consolidation step doesn't finish correctly (no messages, it just doesn't produce the metadata file).
d70-t commentedon Aug 1, 2025
HTTP(S) doesn't specify an operation like
ls. Some webservers implicitly generate an "index" page, i.e. a HTML document which contains links to all directory items. And some libraries (likefsspec) can read such HTML documets and guess form the links inside, how a directory listing might look like.The HTTP frontend of the Swift object store doesn't automatically generate directory listings (and directories don't even really exist on an object store). So there's no HTML document which
fsspeccould use to guess the contents. If consolidated metadata is present, then this metadata document can be (and is) used to extract a list of variables. Thus,zarrdoesn't have to rely on the existence of anlsoperation in the underlying store anymore.