netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Elena Pourmal <epourmal@xxxxxxxxxxxx> writes: > Ed, > > I am curious on which system did it happen. I can suspect only Solaris. > > Elena > Well despite your suspicions it was linux! But it is my development machine,which has a lot of weird stuff going on! Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx ============================================================================== To unsubscribe netcdf-hdf, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ============================================================================== >From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 09 2003 Jul -0600 10:34:00 Message-ID: <wrxu19v7j7r.fsf@xxxxxxxxxxxxxxxxxxxxxxx> Date: 09 Jul 2003 10:34:00 -0600 From: Edward Hartnett <ed@xxxxxxxxxxxxxxxx> To: netcdf-hdf@xxxxxxxxxxxxxxxx Subject: more on netCDF 4 compatibility requirements... Received: (from majordo@localhost) by unidata.ucar.edu (UCAR/Unidata) id h69GY1gj029346 for netcdf-hdf-out; Wed, 9 Jul 2003 10:34:01 -0600 (MDT) Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu [220.127.116.11]) by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h69GY0Ld029340 for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Wed, 9 Jul 2003 10:34:00 -0600 (MDT) Organization: UCAR/Unidata Keywords: 200307091634.h69GY0Ld029340 Received: (from ed@localhost) by rodney.unidata.ucar.edu (8.11.6/8.11.6) id h69GY0B15492; Wed, 9 Jul 2003 10:34:00 -0600 Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx Precedence: bulk Howdy! Here's some more detail on what we expect netCDF 4 to be able to do. Please let me know what you think... * NetCDF File Format Compatability ** NetCDF 4 uses HDF5 as it's storage layer. ** NetCDF 4 can also create/read/modify files created with previous versions of netCDF, using the original netCDF data format. ** If the user opens an old netCDF file, and attempts to modify it, NetCDF 4 will stick with the (old) netCDF file format. New API features (like bit-packing) won't work on these files. ** There will be a way for users to cause an old netCDF file to be copied into the new HDF5 data format. ** NetCDF 4 can read files created with HDF5, but some features will be inaccessible (rasters, for example). Certain group conventions may be required for a HDF5 file to be accessible via netCDF. ** NetCDF 4 can't read HDF 4 files. ** NetCDF 4 has no knowledge of HDF-EOS. * NetCDF API Backward Compatibility ** Interface will be added to, but all existing function calls will remain the same, so that programs written for netCDF 3.x will work for netCDF 4.0 with a simple compile. ** By default, the netCDF 4 API creates HDF5 files. A renamed set of functions allows access to the original 3.x netCDF functions, which allow the users to create netCDF format files.