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

Re: 19991028: NetCDF 3.0

------- Forwarded Message

Date:    Thu, 28 Oct 1999 13:34:26 -0700
From:    "Suzanne T. Rupert" <address@hidden>
To:      Russ Rew <address@hidden>
Subject: Re: 19991028: NetCDF 3.0

Dear Russ,

Thank you for your prompt reply.  NetCDF has been an extremely useful tool
for us, and I hope that my comments will be taken in the spirit in which they
were intended.

I wished to express my concern that the functionality which we have come to
utiize so heavily may disappear, and I am pleased to hear that for the moment
there are no plans to phase it out.  And I also wanted to let the you know
that there are progrmamers out here that find the weak fucntion typing not
only useful, but extremely helpful.

Cheers,
Suzanne

Rew wrote:

> >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

- --
address@hidden
Center for Clouds, Chemistry and Climate
Center for Atmospheric Sciences
Scripps Institution of Oceanography
University of California, San Diego
9500 Gilman Drive #0221
La Jolla, CA  92093
TEL  (858) 534-7513
FAX  (858) 534-7452




------- End of Forwarded Message