Dennis,
Sorry I wasn't very clear. I was trying to be brief. I will give you a
little more detail.
Previous versions of our application wrote netcdf-3 files. Our current
version added new data that takes advantage of groups. We still need to
correctly read old files. We do not want code structures that use:
If (filetype == NETCDF3)
Else (filetype == NETCDF4),
Because it defeats the power of reading data blocks independent of format.
We simply test if data is present and read. This functionality is important
to us because the type of data present in the file varies depending on the
options used to produce the data. Our strategy is to read what's available.
Hence, only a small subset is considered "critical".
Part of that process means we need to be able to check for a group ID. If
the group is present, we read that section. If not, we move on. Under
netcdf-4.1.1 reading an old-style netcdf-3 file, nc_inq_ncid always returned
an error condition (since there are no groups in the file) so everything
worked as expected. Now under netcdf-4.2, function nc_inq_ncid always
returns NC_NOERR, which causes problems because it fools our program into
thinking the group is present even when there are no groups present in the
file.
I know there are workarounds (we already have one in fact), but our code is
much cleaner if we can simply "check-for-data/read-data". We would like to
be able to check for groups, even when we read an older netcdf3 file.
> > I suggest the function have the following behavior:
> >
> > If name corresponds to the root id (i.e. is blank or "/") then the
> > function should behave as it currently does returning NC_NOERR, since
> > that would be a valid call even for version 3 files. Otherwise, the
> > function should return an error condition.
In any case returning NC_NOERR does not make sense, because the group is NOT
in the file. It makes the code cluttered and cumbersome to always test for
filetype>=NETCDF4 before using functions only available to netcdf4 files.
Note, other functions may also be affected. This is the one we encountered
in our travels.
Thanks,
Roy
> -----Original Message-----
> From: Dennis Heimbigner [mailto:dennis.heimbigner@xxxxxxxxx]
> Sent: Tuesday, April 03, 2012 10:52 PM
> To: Roy Dennington
> Subject: Re: [netcdfgroup] Netcdf-4.2 nc_inq_ncid behavior for a group is
> incorrect for Netcdf-3 files
>
> Roy- I am not sure I understand. The group procedures are only valid for
> netcdf-4. So the current behavior of the nc_inq_ncid is in fact correct. I
> assume I am misunderstanding your point.
> Could you please clarify.
>
> =Dennis Heimbigner
> Unidata
>
> Roy Dennington wrote:
> > We currently use the "group" feature in our latest file format. When
> > we read older files (based on Netcdf-3), we discovered that
> > NC3_inq_ncid always returns the file ID as the group ID. We expected
> > the function to return an error, indicating the "group" was not found
> > (similar to the behavior of netcdf-4.1.1).
> >
> >
> >
> > I suggest the function have the following behavior:
> >
> >
> >
> > If name corresponds to the root id (i.e. is blank or "/") then the
> > function should behave as it currently does returning NC_NOERR, since
> > that would be a valid call even for version 3 files. Otherwise, the
> > function should return an error condition.
> >
> >
> >
> > Best Regards,
> >
> > Roy Dennington
> >
> > Semichem, Inc.
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > netcdfgroup mailing list
> > netcdfgroup@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
