ok,I see now.
It seems like a reasonable change, especially
if the behavior used to be different.
I will discuss it locally.
=Dennis Heimbigner
Unidata
Roy Dennington wrote:
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/
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
