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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.