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.
Ed Hartnett wrote:
Ed: Just checking in to see if there's been any further developments on this front. The 5/20 snapshot didn't work with the following code that generates a compound variable from a struct containing a 16 bit integer and a 64 bit integer.Jeff Whitaker <jswhit@xxxxxxxxxxx> writes:Ed Hartnett wrote:Howdy Jeff, Just an update: we have confirmed this bug and I am working on it now. I have also added this to our automatic testing, so that we can see it break here on our test machines, and ensure that once it's fixed, it doesn't break again. I will let you know when this fix is available in the snapshot - hopefully not more than a few days from now... Thanks again for find this! EdEd: Any progress on this one?Howdy Jeff! Yes, there has been much progress, and it you get the snapshot I believe your case will now work. (And if you look in the ncdump and libsrc4 directories you can see where I use your CDL and the files generated from it for a new series of cross-platform testing that's now part of the build.) However I am not done with this problem, there are some other cases that need to be checked (like compound inside of vlen, and vice-versa). So I am still working on the code and adding more cross-platform tests. I have also taken this opportunity for some core libsrc4 refactoring with respect to the handling of user-defined types. I don't think I have yet solved all the compound types problems on all platforms, as my new tests are still causing failures on the IRIX and AIX platforms. I am looking into this now. Also, to answer your original concern, this does not mean that the data files are not portable. They are. The bug was in the way that the netCDF-4 gave out information on the user-defined types in the file. This is why generic read programs (like ncdump) can demonstrate the problem, while cross-platform testing of the compound type do not show the problem. But the files that you created are perfectly fine, and when this bug fix is complete they will be understood properly by ncdump and other programs that generically read a netCDF-4 file with compounds inside compound types. As always, a good way to confirm this is to look at the h5dump output. If h5dump shows the data properly, then it is stored properly in the HDF5 file. Also, since netCDF-4 creates perfectly normal-looking HDF5 files, any HDF5 visualization package can be used on a netCDF-4 file to look at the data. (I don't know if any visualization package can display a data from a compound within a compound type!) I will send out an update when this cross-platform work is complete. Thanks! Ed
#include <stdlib.h> #include <stdio.h> #include "netcdf.h" #define ERRCODE 2 #define ERR(e) {printf("Error: %s\n", nc_strerror(e)); exit(ERRCODE);} int main() { int ncid, typeid, varid, dimid, retval; char name[NC_MAX_NAME + 1]; int dimids[] = {0}; struct s1 { short i; long long j; /*};*/ } __attribute__ ((__packed__)); struct s1 data[1];/* Create some phony data. */ data[0].i = 20000;
data[0].j = 300000; /* Create a file with a compound type. Write a little data. */ if ((retval = nc_create("test.nc", NC_NETCDF4, &ncid))) ERR(retval);; printf("size of compound %d\n",sizeof(struct s1));if ((retval = nc_def_compound(ncid, sizeof(struct s1), "cmp1", &typeid))) ERR(retval);;
printf("offset i %d\n",NC_COMPOUND_OFFSET(struct s1,i)); if ((retval = nc_insert_compound(ncid, typeid, "i", NC_COMPOUND_OFFSET(struct s1, i), NC_SHORT))) ERR(retval);; printf("offset j %d\n",NC_COMPOUND_OFFSET(struct s1,j)); if ((retval = nc_insert_compound(ncid, typeid, "j", NC_COMPOUND_OFFSET(struct s1, j), NC_INT64))) ERR(retval);; if ((retval = nc_def_dim(ncid, "phony_dim", 1, &dimid))) ERR(retval);if ((retval = nc_def_var(ncid, "phony_var", typeid, 1, dimids, &varid))) ERR(retval);
nc_put_var(ncid, varid, data); nc_close(ncid); }If I use the gcc __packed__ attribute to turn off the padding for memory alignment, I get this from an ncdump of the resulting file:
data: phony_var = {20000, 4} ; whereas the correct result data: phony_var = {20000, 30000} ;is obtained when the __packed__ attribute is not set and padding is added for memory alignment. h5dump also displays the same wrong data as ncdump
DATA { (0): { 20000, 4 } }So it appears that the data is being written incorrectly to the file when something other than the default memory alignment is used.
-Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@xxxxxxxx 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
netcdfgroup
archives: