NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Rob Latham <robl@xxxxxxxxxxx> writes: > On Mon, Oct 25, 2010 at 09:16:31AM -0600, Ed Hartnett wrote: >> This problem was caused by an inadvisable call to H5close() inside the >> netCDF library. Of course it was very silly of me to do this - how can >> the netCDF library know if you are still using the HDF5 library? >> >> The call to H5close() was removed, and thus the problem will not occur >> for you. > > I wonder if you added this close some time after this discussion? I added the H5close well after that discussion. I don't think it is related. > > http://mailman.unidata.ucar.edu/mailing_lists/archives/netcdf-hdf/2007/msg00107.html > > and if so, does removing this call have implications for parallel I/O ? The only time this can matter is if a program is using netCDF-4 and HDF5 at the same time. (That is, a program is opening some HDF5 files with the netCDF-4 API, and some with the HDF5 API.) In this case, when the last netCDF file is closed, the netCDF library will close the HDF5 library. This is, of course, a bad thing to do. This will hurt parallel programs the same way that non-parallel programs will be hurting: subseqent calls to open HDF5 objects will fail, because closing the library deleted them from memory. Thanks, Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdfgroup archives: