home / github / issues

Menu
  • GraphQL API
  • Search all tables

issues: 1216517115

This data as json

id node_id number title user state locked assignee milestone comments created_at updated_at closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
1216517115 I_kwDOAMm_X85IgpP7 6517 Loading from NetCDF creates unnecessary numpy.ndarray-views that clears the OWNDATA-flag 16100116 closed 0     6 2022-04-26T21:53:00Z 2023-04-06T03:42:34Z 2023-04-06T03:42:34Z NONE      

What happened?

When loading a NetCDF4 dataset from a file (at least using the 'h5netcdf' engine) I get a xarray.Dataset where each DataArray wraps a numpy.ndarray with the OWNDATA flag set to False. This is counter-intuitive as the high-level user has not knowingly run anything that would create a view/slice to get a second array sharing memory with the "first" array.

This is of course a rather minor issue, but it annoyed me when I was making tools to keep track of which arrays in my dataset were using much RAM, because I had made an option to only show memory usage for the primary/base array, not for possible extra array views that reuse the same memory. With this option enabled, the reported issue however prevents me from getting useful information (just shows nearly zero memory usage) when inspecting a Dataset loaded from NetCDF4-file instead of a "freshly" created or deep-copied Dataset.

What did you expect to happen?

I would prefer the OWNDATA flag to be True as they are from the lower-level h5py-reading of the HDF5-file. After some debugging this means avoiding to do things like array = array[:, ...] at various places in the multiple layers of wrappers that are involved in the dataset-loading, as that would create and return a new ndarray-instance "sharing" (not owning) memory with the original (while no user-accessible reference to the original ndarray that technically "owns" the memory seems to be retained).

See the minimal code example below. It and my patch were made using xarray 0.20.1 with h5netcdf 0.12.0 but looking it looks like the relevant parts of xarray/core/indexing.py are still the same.

Minimal Complete Verifiable Example

Python import xarray as xr import numpy as np ds = xr.Dataset() ds['stuff'] = xr.DataArray(np.random.randn(2), dims='x') path = 'demo.nc' ds.to_netcdf(path, engine='h5netcdf', format='netCDF4', invalid_netcdf=True) ds2 = xr.load_dataset(path, engine='h5netcdf') print(ds2['stuff'].values.flags['OWNDATA']) # initially False, True after patching

Relevant log output

No response

Anything else we need to know?

I patched two parts of xarray/core/indexing.py to solves the issue: xarray core indexing.diff.txt

Testing in other situations will of course be needed to make sure this doesn't disturb anything else, but I hope the general idea would be useful even if some more condition might be needed for when to take the shortcut of returning the original numpy.ndarray rather than a view of it.

Environment

NSTALLED VERSIONS ------------------ commit: None python: 3.7.9 (default, Aug 31 2020, 17:10:11) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 machine: AMD64 processor: Intel64 Family 6 Model 78 Stepping 3, GenuineIntel byteorder: little LC_ALL: None LANG: en LOCALE: (None, None) libhdf5: 1.10.4 libnetcdf: None xarray: 0.20.1 pandas: 1.3.4 numpy: 1.21.5 scipy: 1.7.3 netCDF4: None pydap: None h5netcdf: 0.12.0 h5py: 2.10.0 Nio: None zarr: None cftime: None nc_time_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.10.0 distributed: 2021.10.0 matplotlib: 3.3.2 cartopy: None seaborn: None numbagg: None fsspec: 0.8.3 cupy: None pint: 0.16.1 sparse: None setuptools: 52.0.0.post20210125 pip: 20.3.3 conda: 4.12.0 pytest: 6.2.2 IPython: 7.20.0 sphinx: 3.4.3
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/6517/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  completed 13221727 issue

Links from other tables

  • 1 row from issues_id in issues_labels
  • 6 rows from issue in issue_comments
Powered by Datasette · Queries took 0.624ms · About: xarray-datasette