Re: 19991028: NetCDF 3.0

>To: address@hidden
>From: "Suzanne T. Rupert" <address@hidden>
>Subject: NetCDF 3.0
>Organization: Center for Clouds, Chemistry, and Climate
>Keywords: 199910281802.MAA08889

Hi Suzanne,

> As a heavy user of netCDF I would like to address a change made in
> netCDF v3.0 that will ultimately make netCDF a less portable and
> transparent interface.
> 
> The strong typing that has been built into netCDF v3.0 function calls is
> a most unwelcome modification.  In fact, my staff and I are avoiding
> netCDF 3.0 calls altogether because of this strong typing.

Note that we didn't just add strong typing, we actually weakened the
typing of the input data, so that you can read the values of a
variable into a double array without having to know or care whether
the values were stored in the netCDF file as bytes, shorts, 32-bit
integers, floats, or doubles.  This actually makes writing some
generic utilities easier to write, because you no longer have to have
a switch statement dealing with the different cases for numeric types
of netCDF variables.

> One of our primary duties is to take various data formats and translate
> them into netCDF.  Some of these data files may contain in excess of 80
> variables with a wide range of data types.  Our translators are written
> to identify the variable type within the body of our code, not prior to
> code construction.  Data are manipulated solely through the use of void
> pointers.  General utilities that are not type specific are highly
> preferrable for our purposes.  The introduction of type specific calls,
> and the ultimate phasing out of non-type specific calls, will force us
> to introduce overhead to our code to either type our data or map the
> functions ourselves.
> 
> We currently maintain well over 100,000 lines of code that use the old
> function calls.  The CIDS data distribution system is built around these
> calls.  It is my fervent hope that the future of function mapping of
> netCDF v2.4 function calls to subsequent versions of netCDF is secure.

We have no immediate plans to phase out netCDF 2.4 compatibility, but
are still finding ways to simplify the interfaces with newer languages
such as Fortran 90 and Java.  For example the Fortran 90 interface
reduces 30 nf_get_var and 30 nf_put_var functions to just two generic
functions that are overloaded to call the appropriate function
depending on the number and types of parameters in the invocation.
Unfortunately a void* pointer provides no information about the real
underlying type of the storage, so such simplification through
overloading is not possible in that case.

But thanks for letting us know about your opinion of the netCDF 3
interfaces.  I had to convert the generic utilities ncdump and ncgen
from netCDF 2 to netCDF 3 interfaces, and ultimately I decided the
version using the new interface was better, though the conversion
required some work.  The strong typing has advantages as well as
disadvantages.  And the void* interfaces are still in the netCDF-3
library, they are just not exposed and documented ...

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu