Subject: Re: HDF: machine independent?

From: dilg@ulabsgi (Doug Ilg)
Date: 6 Apr 1994 17:43:41 GMT

Ken Stone ([email-masked]) wrote:
:     Sorry to beat this thing into the ground, but ...

: I found this statement on the net while browsing with Mosaic:

:  > The HDF design is not machine independent, but it defines the  
:  > data completely.

Where on the Web did you find this?  As a former HDF developer, this is
not the way I'd describe HDF, although I suppose it's not a completely
inaccurate statement.

:     If I ship an HDF file that was created on our RS/6000 to someone
: on a VMS machine, will the HDF library handle the translation of 
: bits/bytes/etc?  It doesn't use XDR like netCDF though, right?  

First, yes, HDF will handle the reading/writing of the data you have
tranferred from the RS6000 to the VAX.  However, due to the way FTP
behaves on VMS machines (in particular, the RMS attributes given to
FTP'd files), you need to run the "fixatr" utility once on your newly
FTP'd file to allow HDF to access the file properly.  This utility is
part of the HDF source code distribution and I think it will automatically
get compiled when you build HDF on a VMS machine.

Second, no, HDF does not use XDR, per se.  The library contains its own
conversion routines that are much faster than the XDR library although
they produce IEEE-formatted numbers just like XDR.  These routines also
take advantage of special features on some systems.  For example, Cray
machines running UNICOS have extremely fast vectorized IEEE conversion
routines built into the system.  The HDF library will use calls to the
Cray routines in place of its own functions to do conversions on Crays.

I hope this helps clear things up, Ken.

Doug Ilg
Hughes STX
EOSDIS

---

From: [email-masked] (Chris Houck)
Date: 11 Apr 94 17:33:49 GMT

[email-masked] (Ken Stone) writes:

>|> : I found this statement on the net while browsing with Mosaic:
>|> 
>|> :  > The HDF design is not machine independent, but it defines the  
>|> :  > data completely.
>|> 
>    
>    I found the HDF information in this SDG page...
>    
>http://www.ncsa.uiuc.edu/SDG/Software/Brochure/Overview/HDF.UCD.overview.html

Yup, sure enough it says that.  I've contacted the people in 
charge of that project and they will be fixing this text.

I think they were trying to make a reference to HDF's support
of "native" number types.  If you are on, say, a VAX and know
your file will be staying on VAXen you can have all of your
numbers written out in native VAX format rather than being 
converted to IEEE format in order to save time.  

However, if you then move that file to a Cray you are kinda 
out of luck as far as HDF is concerned.  The library will
tell you "hey neat, there are VAX 32-bit floats here" but will
have no clue about how to convert them to Cray 32-bit floats.

By default, HDF builds itself with local->IEEE and IEEE->local
converters (plus local->PC and PC->local since PCs need all
the spare cycles they can get :-).  We have debated putting in 
local->anything and anything->local but haven't really heard the
demand.

The default is to store numbers in IEEE format, so we assume
that if a user makes the effort to store things in native
format they realize that they may be shooting themselves in
the foot as far as portability is concerned.

I assume that's what the document writer was driving at.  Why
it was brought it up in the context of some other project and
then only given a one sentence explanation is unclear.

-Chris Houck
HDF Group