graphics/opendx and dropping science/hdf

Mike Folk mfolk at
Thu Apr 8 09:12:04 PDT 2004

I completely forgot:  Ireneusz Szczesniak has done an open dx 
implementation called "dxhdf5", and has some nice documentation and other 
materials at   We need to be working 
with her.


(Thanks for cc'ing me Quincey.)
Just a couple other comments about open dx:

The CACTUS project has been using open dx with hdf5 for several years.  I 
strongly suspect there are others, but don't know specifics.  As far as I 
know, the CACTUS folks haven't documented their work (I asked them a few 
times, but that was a couple of years ago), so I don't know exactly how 
they organize the data.

Open dx and hdf5 are a natural combination, and it's a pity we haven't 
married them in some formal way, and we'd love to work with you if you move 
in that direction.


At 09:27 AM 4/8/2004, Quincey Koziol wrote:
>Hi Mikhail,
> > I intend to drop the science/hdf port. It was obsoleted by hdf5 long ago
> > (was it?), it breaks on some some 64bit platforms, it conflicts with
> > math/netcdf.
> >
> > All the technical issues are, probably, fixable, but the obsoleteness
> > makes them not worth the effort. Or so it seems.
> >
> > The only port relying on science/hdf is graphics/opendx and only if
> > WITH_HDF is defined. Unfortunately, opendx does not (yet?) support hdf5.
> >
> > So...
> >       . Does hdf5 really obsolete hdf4?
>     No, they are different file formats & libraries, etc.
> >       . Does hdf support add much value to opendx at all,
> >         or can we just remove it?
>     I don't know.
> >       . If not, should I (or some other helping hand) try to patch
> >         opendx to use hdf5?
>     It would certainly be nice if opendx supported hdf5.
> >               or
> >       . bring the old hdf4 into the 21st century (fixing the types,
> >         depending on math/netcdf instead of building its own)?
>     It shouldn't be _too_ hard to fix the type information in hdf4 (I can 
> help
>you with that, if you'd like), but it would be _very_ hard to depend on
>math/netcdf instead of its own.
>     Quincey
> >
> > Thanks for any ideas,
> >
> >       -mi
> >

Mike Folk, Scientific Data Tech (HDF)
NCSA/U of Illinois at Urbana-Champaign          217-244-0647 voice
605 E. Springfield Ave., Champaign IL 61820     217-244-1987 fax  

More information about the freebsd-ports mailing list