#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? --------------------------+------------------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Resolution: | Keywords: EOS_Omni HDF5 --------------------------+-------------------------------------------------

Comment (by 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.

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

#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? --------------------------+------------------------------------------------- Reporter: bmundim | Owner: knarf Type: enhancement | Status: review Priority: major | Milestone: Component: Other | Version: Resolution: | Keywords: EOS_Omni HDF5 --------------------------+-------------------------------------------------

Comment (by knarf):

Instead of wrapping the hdf5 C functions for fortran, we could also read the table simply in C. Some Fortran is still required because the table needs to be accessible from the fortran module. Patch is attached, please review.

#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? --------------------------+------------------------------------------------- Reporter: bmundim | Owner: knarf Type: enhancement | Status: closed Priority: major | Milestone: Component: Other | Version: Resolution: fixed | Keywords: EOS_Omni HDF5 --------------------------+------------------------------------------------- Changes (by knarf):

* status: review => closed * resolution: => fixed

Comment:

Thanks for the review. I use CCTK_FNAME now, and I changed the value of STEERABLE. Interestingly Cactus accepted RECOVERY (ticket #668). The new patch is applies, closing this ticket.