Re: [netcdfgroup] Files with compound types ARE portable!

  • To: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
  • Subject: Re: [netcdfgroup] Files with compound types ARE portable!
  • From: Jeff Whitaker <jswhit@xxxxxxxxxxx>
  • Date: Wed, 27 May 2009 11:09:49 -0600
Ed Hartnett wrote:
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!

Ed
Ed:  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

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.

#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



  • 2009 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: