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

Re: 970618: Writing varaible size data

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: 970618: Writing varaible size data
  • Date: Thu, 19 Jun 1997 14:22:52 -0600
>To: address@hidden
>From: Laurent LE GAL <address@hidden>
>Subject: Writing varaible size data
>Organization: IFREMER

Hi Laurent,

> I'd like to know if there is an other way to write/read the record-data
> part of a netCDF file than writing/reading the variable data one after
> the other using the put_var/get_var functions. A possible way would be
> to use a fonction writing/reading the record in a single pass (the
> record contents would still be described by the NetCDF variables). I'm
> looking for such a solution to improve to I/O operations of my
> application.

In the netCDF-3 interface, there is no function that writes multiple
variables with a single call.  However, in the netCDF-2 C interface, we
did supply such a function, ncrecput, documented at

    http://www.unidata.ucar.edu/packages/netcdf/guide_9.html#SEC63

This is also available as part of the current netCDF 3.3.1 software
distribution, in the netCDF-2 backward-compatibility interface, so you
can still use it along with the ncrecget function for input.  If you
look at the way it's implemented, it eventually just makes the
appropriate nc_put_var_... calls for each variable.  It provides no
gains in efficiency over making all the individual calls.

The reasons we didn't choose to provide the same functionality in the
netCDF-3 interfaces were:

 - we didn't know how to design a type-safe version that would be
   convenient to use (ncrecput has a void** parameter);

 - we thought it was not possible to conveniently provide automatic type
   conversions between external and internal types in such an interface;

 - we didn't know how to provide the same functionality for Fortran; and

 - we didn't think the interface was used much since it offered no real
   benefits over tailoring your own record I/O function on top of the
   existing netCDF interface.

--Russ

_____________________________________________________________________

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