intended behavior of empty record variables

Hi,

A user recently requested that NCO support empty record variables.
These occur when the record dimension and
associated variables have been defined and before any records have
been stored. Are such "empty-record" files netcdf conformant?

If so, then NCO will try to support them.
However, there are some libnetcdf.a issues that arise.
First nc_get_var? routines return

NC_EINVALCOORDS = Index exceeds dimension bound

when called with arguments start=count=0. Is this logical?
To me, start and count are exactly zero in the absence of any data.
It seems like libnetcdf expects the client program to refrain from
calling nc_get_var? functions for record variables with no data,
even though doing so could be considered legal.

I would appreciate:
1. An explicit statement in the C API guide describing the expected
   library behavior for files with record variables with zero records,
   and how calls with start=count=0 will behave.
2. A more appropriate error message (or no error at all) than
   "Index exceeds dimension bound" for variables that have no data.
   Does an index of zero exceed the dimension bound when the dimension
   bound is also zero?
   I think this case merits a distinct error value/message.
   Or rather, I think that libnetcdf should return no error, nor data,
   to a zero element request for a zero element variable.
   It seems to me that should be legal.
   More important to me than the behavior in this corner-most case is
   an explicit statement somewhere on the expected behavior.

Thanks much,
Charlie
--
Charlie Zender, surname@xxxxxxx, Department of Earth System Science
3228 Croul Hall, UC Irvine, Irvine CA 92697-3100. (949) 824-2987 :)

==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================


  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: