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.
Harvey, > There was discussion in ncdigest V1 #887 on reserving header space using > the double underbar tuning function nc__enddef. > > I believe there is a need to: > > 1. Clarify the status of the three double underbar tuning functions > nc__create, nc__open and nc__enddef > > 2. Make clearer recommendations about their use. > > The NetCDF C Interface Guide contains section 2.10 headed > "Leave Define Mode with Performance Tuning: nc__enddef" with URL > http://my.unidata.ucar.edu/content/software/netcdf/docs/netcdf-c/nc_005f_005fenddef.html > This section contains the following warning paragraph: > > Caution: this function exposes internals of the netcdf version 1 file > format. Users should use nc_enddef in most circumstances. This function > may not be available on future netcdf implementations. > > Does this warning apply to all three tuning functions? No, the tuning parameters available with nc__create() and nc__open() merely specify a property of an open netcdf dataset, not part of the file format. They are not persistent, so not stored in the file. > Are these functions supported by > 1. OPeNDAP (DODS) > 2. netCDF-4? OPeNDAP provides only read access to data on an OPeNDAP server. The nc__create() and nc__enddef() calls are not useful in the context of read-only access. The "chunksize" parameter in nc__open() might be exploited by OPeNDAP for allowing client control of the buffer sizes used for network data access, but as far as I can tell it's currently ignored. Ed Hartnett summarized the situation for netCDF-4: the interfaces with extra tuning parameters are supported, but the tuning parameters are ignored. Similarly, a program that uses the nc__create(), nc__open(), and nc__enddef() interfaces with extra tuning parameters can be linked with the OPeNDAP library, but will not have any effect different from using the simpler nc_create(), nc_open(), and nc_enddef() interfaces. In developing netCDF, we're now more aware of the importance of backward compatibility than when the warning above was written. It's become a fundamental development principle that current and future versions of our netCDF libraries must continue to support both access to earlier forms of netCDF data and linking of programs that use earlier versions of the netCDF API. We'll change the documentation to make clear that the interface will continue to be supported. Thanks for pointing out the need for a clarification. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu
netcdfgroup
archives: