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.
Since this is a rather wide-ranging discussion of opinion, here are my thoughts on netcdf3 vs netcdf4 and the role of Unidata: (1) netcdf3 vs netcdf4: - I appreciate and have used the on-the-fly compression in netcdf4. I don’t have much experience with the other unique features of netcdf4. - Nonetheless, when building applications on a new system, I always link against a stable netcdf3 library, rather than netcdf4. Sometimes I have had compatibility problems between cdo, nco, nccopy, and the netcdf files created on another machine or application. - I had to work around a problem earlier this year due to the underlying reliance on the hdf library in netcdf4. Apparently some of the hdf attributes were hidden to the netcdf interface, and there were problems with conversion of netcdf3 to compressed netcdf4 format. (2) Unidata support: I have always found Unidata/UCAR staff knowledgeable and responsive to problems I have encountered in netcdf releases. I am not entirely sure what language bindings are officially supported at present; a previous post seemed to imply that Python was supported. I think the C and Fortran libraries should be top priority, but if there are resources to support any of the interpreted languages, I vote for support for the Julia language. An interface to the C library already exists, but it is immature and could use some dedicated effort. -Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Edward D. Zaron Research Assistant Professor Department of Civil and Environmental Engineering Portland State University Portland, OR 97207-0751 Phone: (503)-725-2435 FAX: (503)-725-5950 ezaron@xxxxxxx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
netcdfgroup
archives: