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.
Hi Thomas, > I recently started to deal with NetCDF files and first tried to use > the C++ interface. I reverted to the plain C interface because of > what looks like a bug to me: > > I have a variable of type double and tried to read values into a > float array... I'll let the code talk (time is of type double and > only depends on one dimension, namely time): > > NcVar* timo = ncfile->get_var("time"); > cout << "[datagroup] have " << *(timo->edges()) << "times" << endl; > float* thetimes = new float[*(timo->edges())]; > timo->get(thetimes,*(timo->edges())); > for(long i = 0; i <= *(timo->edges()); ++i) > { > cout << "time " << i << ": " << thetimes[i] << endl; > } > > This results in only zeroes being printed. Without the need of conversion > > double* thetimes = new double[*(timo->edges())]; > timo->get(thetimes,*(timo->edges())); > > I see the correct values. It should also be mentioned that the > actual values fit easily in a float number; in fact they are in the > range of 0 to 60 in steps of exactly 0.5. > > When using the classical nc_get_var_float() I have the correct > converted values. > > So, I suspect that the automagic conversion via the overloaded > methods of the NcVar class doesn't really work here. Can one confirm > this or is this just an oddity of my setup/data/compiler? It is an oddity of the C++ interface that the NcVar::get() method returns a boolean whose value is FALSE if the return type requested does not match the external type for the variable. The C++ interface predates the C interface and did not do automagic conversion via overloaded methods, except in the NcVar::as_TYPE() methods. So what you encountered is not strictly a bug, since it matches the documentation: http://www.unidata.ucar.edu/packages/netcdf/docs/netcdf-cxx/Class-NcVar.html Checking the return value of timo->get() would have indicated a problem. However, I think it is unexpected that the overloaded methods don't do the obvious type conversion, since the required information to do the type conversion is available. Thanks for pointing out the problem. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu
netcdfgroup
archives: