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
Relevant log outputNo 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 |