[ET Trac] [Einstein Toolkit] #145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Thu Mar 3 12:25:51 CST 2011
#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
--------------------------+-------------------------------------------------
Reporter: bmundim | Owner: knarf
Type: enhancement | Status: accepted
Priority: major | Milestone:
Component: Other | Version:
Resolution: | Keywords: EOS_Omni HDF5
--------------------------+-------------------------------------------------
Comment (by rhaas):
Replying to [comment:1 knarf]:
> The HDF5 thorn within Cactus builds with Fortran support, so that this
should be available everywhere. A problem with that should be reported. On
the other hand, converting the fortran reading routines to C would not be
hard. That would also be a solution.
I had written a set up C stubs for the HDF5 routines that EOS_Omni uses
some time ago (the patches still apply, with the testing patch shifting by
a line or so). Mostly these were written because libhdf5 does not compile
with the CFLAGS settings I like to use (it uses implicit declaration of
functions).
Since others seem to have trouble getting the FORTRAN interface to work as
well, these might be useful.
The stubs are trying to be careful about mapping HDF5 types to Cactus
types, but they essentially cast all hid_t types to CCTK_INT (and try to
test that this actually worked without loss of information).
Also I hardcoded some options in the stubs that used to be passed as
parameters (mostly because it avoid having to somehow provide #defines for
named constants).
I have tested them (using the second patch) by reading in Chen's EOS table
that Christian provides on stellarcollapse.org and comparing the ASCII
dump of the read in table.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/145#comment:3>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list