Skip to content

DataArray read from netcdf with unexpected type #1842

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mraspaud opened this issue Jan 19, 2018 · 1 comment
Closed

DataArray read from netcdf with unexpected type #1842

mraspaud opened this issue Jan 19, 2018 · 1 comment

Comments

@mraspaud
Copy link
Contributor

Code Sample, a copy-pastable example if possible

import numpy as np
import h5netcdf

filename = "mask_and_scale_float32.nc"

with h5netcdf.File(filename, 'w') as f:
    f.dimensions = {'x': 5}
    v = f.create_variable('hello', ('x',), dtype=np.uint16)
    v[:] = np.ones(5, dtype=np.uint16)
    v[0] = np.uint16(65535)
    v.attrs['_FillValue'] = np.uint16(65535)
    v.attrs['scale_factor'] = np.float32(2)
    v.attrs['add_offset'] = np.float32(0.5)


import xarray as xr

v = xr.open_dataset(filename, mask_and_scale=True)['hello']
print(v.dtype)

Problem description

The scale_factor and add_offset being float32, I would expect the result from loading to be a float32 array. However, we get a float64 array instead. A float32 array for a very large dataset is better for faster computations.

Expected Output

float32

Output of xr.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 2.7.5.final.0 python-bits: 64 OS: Linux OS-release: 3.10.0-693.11.6.el7.x86_64 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_GB.UTF-8 LOCALE: None.None

xarray: 0.10.0
pandas: 0.21.0
numpy: 1.13.3
scipy: 0.18.1
netCDF4: 1.1.8
h5netcdf: 0.4.2
Nio: None
bottleneck: None
cyordereddict: None
dask: 0.16.0+37.g1fef002
matplotlib: 2.1.0
cartopy: None
seaborn: None
setuptools: 38.2.4
pip: 9.0.1
conda: None
pytest: 3.1.3
IPython: 5.5.0
sphinx: 1.3.6

@fmaussion
Copy link
Member

Seems like this issue is a good use case for #1840 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants