[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 19991028: NetCDF 3.0
- Subject: Re: 19991028: NetCDF 3.0
- Date: Thu, 28 Oct 1999 14:52:59 -0600
------- 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