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

Re: 19980526: netCDF 3.4 question

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.

  • Subject: Re: 19980526: netCDF 3.4 question
  • Date: Tue, 26 May 1998 12:47:18 -0600
>To: address@hidden
>cc: address@hidden (John Lewis)
>From: "John B. Lewis" <address@hidden>
>Subject: netCDF 3.4 question
>Organization: NOAA/FSL
>Keywords: 199805261759.LAA14456

Hi John,

> I have been working with netCDF 3.4 and linking it with our existing
> netCDF programs. All of our existing netCDF software is written using
> the netCDF 2.x function calls. I have not experienced any problems
> with linking or running these programs on SGI or Solaris platforms.
> 
> My concerns are: 
> 
> 1) Will future releases of netCDF also be backward compatable with
>    netCDF 2.x?

It's our intention to continue to support the interfaces people find
most useful, so we don't have any immediate plans to stop supporting the
netCDF 2.x interface, though we won't be extending it or providing a
Fortran-90 version of the 2.x interface.  The newer 3.x interface has
some attractive features, but if the benefits aren't worth the cost of
converting, you can stay with the 2.x interface.  The 2.x interface is
now written in terms of the 3.x interface, so if the 3.x interface
works, the 2.x interface should also.

> 2) If not, when will incompatability become an issue?

Incompatibility may possibly become an issue when trying to make
applications that use netCDF 2.x interfaces thread-safe on multi-CPU
architectures, so you can get the benefits of parallel execution.  There
are problems with the 2.x interfaces that make it not worth the effort
to try to make them thread-safe.  (The 3.x implementation is not yet
thread-safe either, but we think it will be fairly easy to make it
thread-safe.)

--Russ

_____________________________________________________________________

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