This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
------- 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