#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.