[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

> Organization: NCAR/HAO
> Keywords: 199401311938.AA28870

Ben,

> Yes, thanks Russ. I've just obtained a copy of the v2.3 guide,
> and I see that it is correct there. I'm creating files on shavano,
> which I think is currently running v2.0. I'm assuming there are
> no major changes from 2.0 to 2.3 (?? -- I'm debugging some
> code, and have discovered that positioning write statements on
> either side of ncvpt calls is changing the crashes...)

There were numerous bugs fixed between 2.0 and 2.3, and some additional
interfaces added.  I've appended a list of the differences from the
announcement of the new version, last April.

--Russ

 All reported problems with the beta version have been fixed, and the
 software has been ported to several additional architectures.  This release
 has been built and tested successfully on the following platforms:

         CRAY Y-MP      UNICOS 6.1.6
         DEC VAX                VMS V5.5-2
         DECstation     ULTRIX V4.3
         HP-9000/7xx    HPUX 9.0
         IBM PS/2       MSDOS 5.0
         IBM PS/2       OS/2 1.3
         IBM RS-6000    AIX 3.2
         SGI Iris       IRIX 4.0.5
         SPARCstation   Solaris 2.1
         SPARCstation   SunOS 4.1.3

 Our experience indicates that this version of netCDF is relatively easy to
 port to other Unix systems.  The new `configure'-based approach to
 installation has a good chance of working on other platforms without
 requiring significant changes to the source, since it tests and adapts to
 what the operating system provides.

                           What's New in netCDF 2.3

 Subsampling along specified dimensions (using `strides') is now supported by
 new C and Fortran interfaces for generalized hyperslab access (ncvarputg,
 ncvargetg, NCVPTG, NCVPGC, NCVGTG, and NCVGGC).  In addition, these new
 interfaces also permit accessing data that is not contiguous in memory.  In
 a generalized hyper.
 slab, an `index mapping vector' is used to define the
 mapping between points in the generalized hyperslab and the memory locations
 of the corresponding values.  This facility can be used to avoid copying
 data into or out of a contiguous array solely for netCDF access.

 There are also some new C interfaces (ncrecput, ncrecget, and ncrecinq) that
 can be used to write, read, and inquire about records, where a record may
 contain multiple variables of different types and shapes.  With the new
 interfaces, you can access a record's worth of data (or some subset of a
 record) with a single call, instead of the multiple calls required with the
 previous version.

 New optimizations for the library have resulted in significant speedups for
 accessing cross-sections involving non-contiguous data.  In some cases,
 speedups by a factor of 40 are achieved with the new implementation of I/O,
 and the new design isolates the I/O layer to make other platform-specific
 optimizations easier.

 The ncdump utility now supports several new command-line options including
 the ability to specify variables and to provide value annotations.

 The way in which all the default fill values are defined in the FORTRAN
 interface was changed, so that now the FORTRAN default fill values will
 always be the same as the C default values.  This eliminates the need for
 some platform-specific files where these constants were previously defined.

 The new release is intended to be backward-compatible with previous
 releases, adding a few new interfaces but not changing existing interfaces.
 The file format for netCDF files remains the same.  

 The one change that might be a problem for some users is a new definition
 for the default floating-point fill values (FILL_FLOAT and FILL_DOUBLE in
 the C interface, FILFLOAT and FILDOUB in FORTRAN interface).  Previously
 these had been defined to be values that, on writing, would map into the XDR
 representation for IEEE infinity.  The idea was that although the values
 that had th.
 is property might vary from platform to platform, the on-disk
 representation for missing floating-point data would at least be the same
 for all platforms.  But such fill values turn out to be an obstacle to
 writing portable generic netCDF applications, since there is no portable way
 to determine if a floating-point value is an IEEE infinity, and using
 ordinary comparisons with such numbers can produce errors or surprising
 results.  The old default floating-point fill values also introduced an
 undesirable dependence on the compilation environment used when the netCDF
 library was installed.  Solving these problems led to the definition of new
 default floating-point fill values.  These are intended to be portable
 across all platforms and compilation environments.  If you wish, however, to
 obtain the old, non-portable floating-point fill values, then this is
 possible by following the instructions in the INSTALL file.

 The suggested extension for netCDF files has been changed from `.cdf' to
 `.nc', in order to avoid a clash with the NASA CDF file extension.  Although
 the old extension is still supported in a backward compatible way (ncgen -n
 still produces `.cdf' files), new netCDF files should use the new filename
 extension, where practical.  A new `-b' flag to ncgen generates binary files
 with the new extension.

 The code now conforms to the C Standard, although it can still be built with
 non Standard C compilers such as the SunOS /bin/cc.  Many `const'
 declarations were added to the interfaces and documentation, to specify
 where functions do not change values through pointers.

 Many changes were made to the User's Guide and man pages to improve the
 documentation and describe the new interfaces.  A new Appendix includes some
 answers to frequently asked questions.  Among the changes, it is now made
 clearer in the User's Guide that a NULL pointer can be provided for any
 return parameter from an inquire function to indicate where a value should
 not be returned, and that in.
 quire functions do not incur any I/O.

 A draft prototype C++ interface has been added.  See the c++ subdirectory
 for the implementation, an example of use, and some preliminary
 documentation.  If you use this, please send us feedback about how useful it
 was and any problems you encountered.

 Questions or comments about the new release that are of general interest may
 be posted to this list (address@hidden).  Specific questions
 or bug reports should be sent to address@hidden.

 ________________________________________________________________________
 Russ Rew                                       Unidata Program Center
 address@hidden                         UCAR, PO Box 3000
                                                 Boulder, CO 80307-3000