NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup archives: