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

[netCDF #GPR-287619]: netcdf_c++ bug in 4.1.3?

Hi Phil,

> I've encountered what may be a bug in the netcdf C++ library for version
> 4.1.3, running under RHEL 5.7 (Tikanga).

The C++ library version in 4.1.3, from the cxx directory, was intended for 
netCDF classic format files. Are you actually using the experimental cxx4 
library from the cxx4 directory?

> I have a netCDF4 format data file with the following properties (output
> from ncdump -h):
>
> netcdf power_test1 {
> dimensions:
> time = UNLIMITED ; // (2528 currently)
> bolodim = 384 ;
> variables:
> int ac_bolos(time, bolodim) ;
> ac_bolos:matrix = 1L ;
> ac_bolos:units = "bits" ;
> double timestamp(time) ;
> timestamp:units = "seconds" ;
> }

So I assume "ncdump -k power_test1.nc" outputs "netCDF-4" for the file format.

The "1L" type for the bolos:matrix attribute indicates an attribute of
type int64 rather than int.  NetCDF-4 files can use 6 primitive types that
are not in the netCDF classic data model, including NC_INT64 which has the
value 10.

> I was attempting to read this file into kst, using a custom version of
> netcdf.cpp to get kst to interpret ac_bolos as a set of vectors rather
> than frames (this is the purpose of the "matrix" attribute). kst would
> crash as soon as I attempted to do anything. (There was no problem using
> the default netcdf.cpp, but kst does not correctly interpret the ac_bolos
> array in that case.) I eventually tracked the cause to a call to as_int(0)
> in the following block of code (line 7) from the netcdf.cpp file:
> 
> nAtts = var->num_atts();
> if(nAtts != 0) {
> NcAtt* att;
> for(int j = 0; j < nAtts; ++j) {
> att = var->get_att(j);
> if(strcmp(att->name(), "matrix") == 0) {
> isMatrix = att->as_int(0) ? true : false;
> break;
> }
> delete att;
> }
> 
> While the call to NcAtt name() correctly returns "matrix" as the attribute
> name, inserting a call to type() returns the incomprehensible result "type
> = 10" (instead of ncInt, or ncDouble, etc.), which I assume is the cause
> of the crash.
> 
> Commenting out the as_int call and simply setting isMatrix true if the
> matrix attribute is present eliminated the problem and kst reads the files
> with no trouble. Neither ncdump (as shown above) nor Matlab's ncdf
> routines have any difficulty in correctly interpreting the contents of the
> .nc file, which leads me to wonder if this is the result of a bug in the
> netcdf library we are using.
> 
> Our netcdf was built from
> 
> http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.1.3.tar.gz
> 
> with
> 
> libnetcdf_c++.so -> libnetcdf_c++.so.4.1.0*

From your use of the as_int() method, it looks like you're trying to use the
old C++ code for classic format files on a new netCDF-4 format file which is
making use of extended types in the netCDF-4 data model.  I'm surprised that
the old cxx API can even open a netCDF-4 file; it should just return an
unrecognized file type of error when that is attempted.

The C++ API we have for netCDF-4 files is in the cxx4 directory and is only
built if you use the --enable-cxx-4 flag to configure.  There's a stand-alone 
version of the netCDF-4 C++ libraries, separated out from the C software, as
announced here:

  
http://www.unidata.ucar.edu/mailing_lists/archives/netcdfgroup/2011/msg00365.html

and documented here:

  http://www.unidata.ucar.edu/software/netcdf/docs/cxx4/

I'm still not sure what the bug is you've encountered, but I hope the 
information
above clarifies the current status of the netCDF-4 C++ libraries.

--Russ

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



Ticket Details
===================
Ticket ID: GPR-287619
Department: Support netCDF
Priority: Normal
Status: Closed