xarray Internals¶
xarray builds upon two of the foundational libraries of the scientific Python stack, NumPy and pandas. It is written in pure Python (no C or Cython extensions), which makes it easy to develop and extend. Instead, we push compiled code to optional dependencies.
Variable objects¶
The core internal data structure in xarray is the Variable
,
which is used as the basic building block behind xarray’s
Dataset
and DataArray
types. A
Variable
consists of:
dims
: A tuple of dimension names.data
: The N-dimensional array (typically, a NumPy or Dask array) storing the Variable’s data. It must have the same number of dimensions as the length ofdims
.attrs
: An ordered dictionary of metadata associated with this array. By convention, xarray’s built-in operations never use this metadata.encoding
: Another ordered dictionary used to store information about how these variable’s data is represented on disk. See Reading encoded data for more details.
Variable
has an interface similar to NumPy arrays, but extended to make use
of named dimensions. For example, it uses dim
in preference to an axis
argument for methods like mean
, and supports Broadcasting by dimension name.
However, unlike Dataset
and DataArray
, the basic Variable
does not
include coordinate labels along each axis.
Variable
is public API, but because of its incomplete support for labeled
data, it is mostly intended for advanced uses, such as in xarray itself or for
writing new backends. You can access the variable objects that correspond to
xarray objects via the (readonly) Dataset.variables
and
DataArray.variable
attributes.
Duck arrays¶
Warning
This is a experimental feature.
xarray can wrap custom duck array objects as long as they define numpy’s
shape
, dtype
and ndim
properties and the __array__
,
__array_ufunc__
and __array_function__
methods.
In certain situations (e.g. when printing the collapsed preview of
variables of a Dataset
), xarray will display the repr of a duck array
in a single line, truncating it to a certain number of characters. If that
would drop too much information, the duck array may define a
_repr_inline_
method that takes max_width
(number of characters) as an
argument:
class MyDuckArray:
...
def _repr_inline_(self, max_width):
""" format to a single line with at most max_width characters """
...
...
Extending xarray¶
xarray is designed as a general purpose library, and hence tries to avoid including overly domain specific functionality. But inevitably, the need for more domain specific logic arises.
One standard solution to this problem is to subclass Dataset and/or DataArray to add domain specific functionality. However, inheritance is not very robust. It’s easy to inadvertently use internal APIs when subclassing, which means that your code may break when xarray upgrades. Furthermore, many builtin methods will only return native xarray objects.
The standard advice is to use composition over inheritance, but reimplementing an API as large as xarray’s on your own objects can be an onerous task, even if most methods are only forwarding to xarray implementations.
If you simply want the ability to call a function with the syntax of a
method call, then the builtin pipe()
method (copied
from pandas) may suffice.
To resolve this issue for more complex cases, xarray has the
register_dataset_accessor()
and
register_dataarray_accessor()
decorators for adding custom
“accessors” on xarray objects. Here’s how you might use these decorators to
write a custom “geo” accessor implementing a geography specific extension to
xarray:
import xarray as xr
@xr.register_dataset_accessor("geo")
class GeoAccessor:
def __init__(self, xarray_obj):
self._obj = xarray_obj
self._center = None
@property
def center(self):
"""Return the geographic center point of this dataset."""
if self._center is None:
# we can use a cache on our accessor objects, because accessors
# themselves are cached on instances that access them.
lon = self._obj.latitude
lat = self._obj.longitude
self._center = (float(lon.mean()), float(lat.mean()))
return self._center
def plot(self):
"""Plot data on a map."""
return "plotting!"
This achieves the same result as if the Dataset
class had a cached property
defined that returns an instance of your class:
class Dataset:
...
@property
def geo(self):
return GeoAccessor(self)
However, using the register accessor decorators is preferable to simply adding
your own ad-hoc property (i.e., Dataset.geo = property(...)
), for several
reasons:
It ensures that the name of your property does not accidentally conflict with any other attributes or methods (including other accessors).
Instances of accessor object will be cached on the xarray object that creates them. This means you can save state on them (e.g., to cache computed properties).
Using an accessor provides an implicit namespace for your custom functionality that clearly identifies it as separate from built-in xarray methods.
Note
Accessors are created once per DataArray and Dataset instance. New
instances, like those created from arithmetic operations or when accessing
a DataArray from a Dataset (ex. ds[var_name]
), will have new
accessors created.
Back in an interactive IPython session, we can use these properties:
In [1]: ds = xr.Dataset({"longitude": np.linspace(0, 10), "latitude": np.linspace(0, 20)})
In [2]: ds.geo.center
Out[2]: (10.0, 5.0)
In [3]: ds.geo.plot()
Out[3]: 'plotting!'
The intent here is that libraries that extend xarray could add such an accessor to implement subclass specific functionality rather than using actual subclasses or patching in a large number of domain specific methods. For further reading on ways to write new accessors and the philosophy behind the approach, see GH1080.
To help users keep things straight, please let us know if you plan to write a new accessor for an open source library. In the future, we will maintain a list of accessors and the libraries that implement them on this page.
To make documenting accessors with sphinx
and sphinx.ext.autosummary
easier, you can use sphinx-ext-autosummary.
Zarr Encoding Specification¶
In implementing support for the Zarr storage format, Xarray developers made some ad hoc choices about how to store NetCDF data in Zarr. Future versions of the Zarr spec will likely include a more formal convention for the storage of the NetCDF data model in Zarr; see Zarr spec repo for ongoing discussion.
First, Xarray can only read and write Zarr groups. There is currently no support
for reading / writting individual Zarr arrays. Zarr groups are mapped to
Xarray Dataset
objects.
Second, from Xarray’s point of view, the key difference between NetCDF and Zarr is that all NetCDF arrays have dimension names while Zarr arrays do not. Therefore, in order to store NetCDF data in Zarr, Xarray must somehow encode and decode the name of each array’s dimensions.
To accomplish this, Xarray developers decided to define a special Zarr array
attribute: _ARRAY_DIMENSIONS
. The value of this attribute is a list of
dimension names (strings), for example ["time", "lon", "lat"]
. When writing
data to Zarr, Xarray sets this attribute on all variables based on the variable
dimensions. When reading a Zarr group, Xarray looks for this attribute on all
arrays, raising an error if it can’t be found. The attribute is used to define
the variable dimension names and then removed from the attributes dictionary
returned to the user.
Because of these choices, Xarray cannot read arbitrary array data, but only
Zarr data with valid _ARRAY_DIMENSIONS
attributes on each array.
After decoding the _ARRAY_DIMENSIONS
attribute and assigning the variable
dimensions, Xarray proceeds to [optionally] decode each variable using its
standard CF decoding machinery used for NetCDF data (see decode_cf()
).
As a concrete example, here we write a tutorial dataset to Zarr and then re-open it directly with Zarr:
In [4]: ds = xr.tutorial.load_dataset("rasm")
In [5]: ds.to_zarr("rasm.zarr", mode="w")
Out[5]: <xarray.backends.zarr.ZarrStore at 0x7f90709be720>
In [6]: import zarr
In [7]: zgroup = zarr.open("rasm.zarr")
In [8]: print(zgroup.tree())
/
├── Tair (36, 205, 275) float64
├── time (36,) float64
├── xc (205, 275) float64
└── yc (205, 275) float64
In [9]: dict(zgroup["Tair"].attrs)
Out[9]:
{'_ARRAY_DIMENSIONS': ['time', 'y', 'x'],
'coordinates': 'yc xc',
'long_name': 'Surface air temperature',
'time_rep': 'instantaneous',
'type_preferred': 'double',
'units': 'C'}