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.

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.

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...

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.

Hello, thanks for the immediate reply - and to seize the opportunity: thanks for this really great library, which I think will be the enabler for me to - finally - use netCDF4 for my measurement facility like I wished for years now. However, I have to disagree in your point regarding the not fitting dimensions in the DataArray definition. np.zeros() will for sure return an n-dimensional array when called with a length-n list as argument, which I did with n=3 and the list [1,2,3]. I.e. calling np.zeros([1, 2, 3]) will return array([ [ [ 0., 0., 0.], [ 0., 0., 0.] ] ])

Besides, the working alternatives with tuples or the OrderedDict use the very same dummy array for initializing in the example above.

Further I estimate the 0.8.2-error-message completely consistent: it (silently) acknowledges that there are three dimensions in both the zeros-array and the coords by reporting a problem about not fitting lengths of the third one of each, 'z'.

Though by adding a one-dimensional dims-definition, you turn the following error messages away from the original problem, now indeed introducing an inconsistency in dimensions between dims and data.