NOTE: The netcdf-hdf
mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, > Greetings to HDF HQ from NetCDFville. I see we're both early risers this morning... :-) > I wonder how often you guys have to change the underlying binary > format of the data in support of new releases of HDF5? We've tweaked the file format a little bit with each major release so far (and sometimes with minor releases also). This shouldn't be a problem for applications which call the library though, since we provide full backward compatability. (and as much forward compatibility as possible) > And is there some format version number in the data file? I presume > there is. We've learned that a single version number is not very useful, so we've learned to include version #'s on all the structures inside the file (we missed a couple, but I'm trying to correct that :-). This "micro-versioning" has been very useful and should allow us to avoid major revisions of the "entire" format for the foreseeable future. Quincey >From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 25 2003 Oct -0600 07:01:55 Message-ID: <wrxekx1xygs.fsf@xxxxxxxxxxxxxxxxxxxxxxx> Date: 25 Oct 2003 07:01:55 -0600 From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx> To: netcdf-hdf@xxxxxxxxxxxxxxxx Subject: important implementation note for range checking and type conversion... Received: (from majordo@localhost) by unidata.ucar.edu (UCAR/Unidata) id h9PD1u0q015504 for netcdf-hdf-out; Sat, 25 Oct 2003 07:01:56 -0600 (MDT) Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu [128.117.140.88]) by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h9PD1tOb015474 for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Sat, 25 Oct 2003 07:01:55 -0600 (MDT) Organization: UCAR/Unidata Keywords: 200310251301.h9PD1tOb015474 Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx Precedence: bulk Quincey, Russ points out that my code allocates giant chunks of memory to convert data types. I only did this because I figure you'll supplant all this code shortly anyway. Presumably your code will have a reasonable memory allocation strategy, such that you're not grabbing giant chunks of RAM, nor doing separate small allocations millions of times. Right? The final work on signed vs. unsigned NC_BYTE is that, except for range checking, we never care, and the information (i.e. whether NC_BYTE data are signed or unsigned) is not stored in the file. The user just has to know that for themselves. For the purposes of range checking, we treat all NC_BYTE data as signed. This will result in errors when the user is actually intending this to be unsigned data, but we can live with that. Ed >From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 25 2003 Oct -0600 07:05:13 Message-ID: <wrxad7pxyba.fsf@xxxxxxxxxxxxxxxxxxxxxxx> Date: 25 Oct 2003 07:05:13 -0600 From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx> To: netcdf-hdf@xxxxxxxxxxxxxxxx Subject: how about adding cygwin to the list of supported HDF platforms? Received: (from majordo@localhost) by unidata.ucar.edu (UCAR/Unidata) id h9PD5E2I018995 for netcdf-hdf-out; Sat, 25 Oct 2003 07:05:14 -0600 (MDT) Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu [128.117.140.88]) by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h9PD5DOb018893 for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Sat, 25 Oct 2003 07:05:13 -0600 (MDT) Organization: UCAR/Unidata Keywords: 200310251305.h9PD5DOb018893 Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx Precedence: bulk Howdy HDF HQ! How about adding Cygwin to the supported platforms? In terms of porting it is almost identical to linux, and lots of people use it, and, most importantly, I use it... I'm about to grab the 1.6.1 source and try it, so I'll let you know how it comes out. Thanks, Ed
netcdf-hdf
archives: