issue_comments

Ok - thanks for clarification. I remember the NC_SHARE flag for the open function in the netcdf-C-api... But I also think your advice is reasonable.

Just to be clear -- you overrode the file on disk while you had it open in another session? Indeed, that is definitely not a recommended workflow, so I'm not surprised things broke. An error would have been friendlier than silent corruption, but maybe the netcdf devs have reasons for this behavior.

Xarray loads data from disk lazily by default, so if you want to overwrite the data on disk you should call .load() or .compute() first. But generally, I recommend always creating new files. Treating data files as immutable makes it much harder to accidentally overwrite the wrong data.

Ok I was not sleeping while reporting this issue... :-) Just if others examine the same problems - or perhaps someone can explain to me...: The reason for strange data in loaded nc-files was as far as I can see because I saved the same file in different versions - although already loaded - and then loaded again. This seems to me is not a good idea. Perhaps things even went worse because I had two instances of Spyder running, happily switching from one to the other saving and loading the file in order to find problems dependent on library versions. But the problem was just this whole procedure itself. The only thing I still don't really know now is what exactly is forbidden or what is the recommended kind of handling - as saving and loading again is imo not an unconventional or unusual part of a workflow...

Hello, by comparing different files with different encodings I have to admit that I cannot reproduce the issue named in the title. In contrast, the erroneous behaviour seems to explicitly origin from my implementation of scale- and offset encoding and in no way from any library- or distribution-version. I definitely thought I checked that first - so sorry for opening an issue on that here and however thanks for helping out.

Ok, understood. In WinPython 3.4 / xarray 0.7.0: Python import netCDF4 as nc nc.__hdf5libversion__ Out[2]: '1.8.15-patch1' nc.__netcdf4libversion__ Out[3]: '4.3.3.1' In WinPython 3.5 / xarray 0.9.0: Python import netCDF4 as nc nc.__hdf5libversion__ Out[2]: '1.8.18' nc.__netcdf4libversion__ Out[3]: '4.4.1.1' That's the easy part - I still play around with loading the files with netCDF4.Dataset() - but I'm not quite sure how to interpret the results and compare it to the data loaded by xarray.

@SpghttCd These are underlying C libraries used by netCDF4-python. For example, on my machine: ``` In [1]: import netCDF4

In [2]: netCDF4.hdf5libversion Out[2]: '1.8.17'

In [3]: netCDF4.netcdf4libversion Out[3]: '4.4.1' ```

Please check if you get different data just using netCDF4, in which case we can report the issue upstream.

No, you're right. I think almost everything changed, because the jump to 0.9.0 happened because of the switch to the latest WinPython-Distribution. What I can read out is the version of netCDF4 in Python, which was 1.2.2 in the former WinPython-package and now is 1.2.7 in the latest. But regarding your question about libnetcdf and hdf5 I think I don't understand enough: are these also python libraries? hdf5 isn't there, only h5py which I thought was an alternative, not a requirement to netcdf4, and libnetcdf I cannot find at all...

Are you sure that the only difference is the version of xarray? This feels like a difference in the underlying libraries -- xarray doesn't do any decoding for data that is stored as doubles without scale and add_offset.

If you're using netCDF4-python to read the data (which is the default), could you please check the versions of netCDF4-python, libnetcdf and hdf5? That would help track down if this is an xarray issue or an issue with an underlying library..

Of course (ncdump -h): netcdf \15_m_erster\ Test_360_d01 { dimensions: D1 = 3601 ; Z = 5 ; X = 5 ; variables: double D1(D1) ; string D1:units = "┬░" ; double Z(Z) ; string Z:units = "mm" ; double X(X) ; string X:units = "mm" ; double Brad(D1, Z, X) ; string Brad:units = "mT" ; double Btan(D1, Z, X) ; string Btan:units = "mT" ; double Bax(D1, Z, X) ; string Bax:units = "mT" ; double T(D1, Z, X) ; string T:units = "degC" ; } I can add the before mentioned integer compressed version, too, if needed. But there's no difference regarding the issue and it's a little longer of course.

Can you report what the raw dataset looks like, either with ncdump -h or xr.open_dataset(filename).info() (on xarray v0.9)?