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 Felipe, > I have found out that NetCDF-4 ignores the offsets that the users specifies > when creating compound types. Instead, I think it calculates the offsets > taking into account the architecture alignment rules. > > So it is not possible for example to create a compound offset without > defining a "struct" in your C program. My problem is that I need to write a > program that is able to create arbitrary compound objects. It *is* possible to create a compound offset without defining a struct in your C program. For example, ncgen uses CDL input describing a compound type to generate a corresponding netCDF file at run time, without a corresponding struct. Also the new nccopy utility uses only the netCDF C API to structurally copy netCDF files, so when it copies a netCDF-4 file with a compound type, it must create the necessary type in the target file without having a corresponding C struct. As an example, consider the following CDL file, fb.cdl: netcdf fb { types: compound mystruct_t { byte field1; int field2; float field3; }; // mystruct_t variables: mystruct_t cvar; data: cvar = {123, 0, 45.67}; } If you use the ncgen in the current snapshot release (previously named ncgen4 in the 4.0.1 release), it creates the corresponding netCDF file, as ncdump verifies: $ ncgen -k 3 -b fb.cdl $ ncdump fb.nc netcdf fb { types: compound mystruct_t { byte field1 ; int field2 ; float field3 ; }; // mystruct_t variables: mystruct_t cvar ; data: cvar = {123, 0, 45.67} ; } Furthermore, you can use ncgen to generate a corresponding C program, compile and run it, and you will still get the same netCDF file. The generated C program does use a C struct for simplicity. $ ncgen -k 3 -lc fb.cdl > fb.c $ cc `nc-config --cflags` fb.c -o fb `nc-config --libs` $ ./fb $ ncdump fb.nc [ ... same result as above] > Another thing that is not possible is to create a compound type that is an > extract (a subset) of a larger struct. In the following simplified example, > I have a struct with 3 fields, but I want to write to disk only the 1st and > the 3rd fields: > > //////////////////////////// > > struct mystruct { > char field1; > int field2; > float field3; > }; > struct mystruct myvar; > myvar.field1=123; > myvar.field3=45.67; > > nc_def_compound(ncid, sizeof(struct mystruct), "MYSTRUCTEXTRACT", &typeid); > nc_insert_compound(ncid, typeid, "FIELD1", 0, NC_BYTE)==0); > nc_insert_compound(ncid, typeid, "FIELD3", NC_COMPOUND_OFFSET(struct > mystruct, field3), NC_FLOAT); > > nc_def_var(ncid, "CVAR", typeid, 0, NULL, &varid); > nc_put_var(ncid, varid, &myvar); > > //////////////////////////// > > The file that I create does not contain the right value for "FIELD3", and I > think the reason is that the library is ignoring the offset that I am > supplying. If you edit the generated C program, fb.c, and comment out the line inserting the "field2" member, it still works, and when run shows a compound type with only the first and third field and the correct value for the field3 member: netcdf fb { types: compound mystruct_t { byte field1 ; float field3 ; }; // mystruct_t variables: mystruct_t cvar ; data: cvar = {123, 45.67} ; } It's possible that the different results you are seeing are from bugs in an earlier version or indicate a new platform-specific bug we haven't seen, but we can't reproduce the problem here. --Russ
netcdfgroup
archives: