Hi Roy, On Sat, Jun 23, 2018 11:45:47 -0700, Roy Mendelssohn - NOAA Federal wrote: > Okay I did some more testing. I used R and the package "ncdf4" and it > was able to read the file. I also tried in python netCDF4 and xarray > and they both failed on the call to open the file. For python I am > running 3.6.4, the conda distribution, with the latest packages. > > I believe that the R package ncdf4 is linked to an earlier version of > the netcdf library, which must be more forgiving of the bad offset. > But as I said, on my machine (MacBook pro, osx 10.13.5) two > versions of ncdump fail on the file (the one that comes with anaconda > and the one that comes with fink), and two python programs fail to > open it. > > This suggests the package that is creating the files is using an older > version of the library and also somehow creating corrupt files. The > information sent by Wei-keng is pretty definitive - the offset at the > start of the file is incorrect. > I agree. I did some more digging in too, and it looks like the nibabel code has custom bits to manage the MINC format's files[1]. The developer that opened the pull request says in the code review[2]: "This is a generic issue with this NetCDF library, in that a NetCDF variable can have a data offset pointing to the end of the file. I've created a test case, but the current code fails if mmap is enabled. I have a more elaborate fix that avoids these failures." These customizations for the MINC format are not included in the scipy netcdf module (and the standard netcdf libraries either, of course). Thanks for the help. I'll inform both nibabel and scipy upstreams and see how they want to handle it. [1] https://github.com/nipy/nibabel/pull/493/files [2] https://github.com/nipy/nibabel/pull/493/commits/8ea59d6f4b46597da0bcfdcb6638dbcfbfd87a3d -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha
Attachment:
signature.asc
Description: PGP signature
netcdfgroup archives: