- removed comment
EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
Issue #145
closed
At the moment EOS_Omni requires the HDF5 library to read the nuclear EOS values from a table. Since not all distros have fortran support for the HDF5 library as a default, I propose to change this requirement and provide a fall back in case this support is not present. Perhaps not using the nuclear EOS, or reading from an ASCII file instead. This could be just a temporary solution until the HDF5 library build script becomes more robust.
Opinions?
Thanks, Bruno.
Keyword: EOS_Omni
Keyword: HDF5
Comments (8)
-
-
- changed status to open
- assigned issue to
- removed comment
-
- removed comment
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.
-
- changed status to open
- removed comment
-
- removed comment
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.
-
- removed comment
This is a good idea.
Mapping between C and Fortran mangled names should use CCTK_FNAME(allocate_eosmodule), since different Fortran compilers use different conventions.
STEERABLE settings include recover, not recoverY. Is there no error reported for this?
Approved with these modifications.
-
- changed status to resolved
- removed 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. -
- edited description
- changed status to closed
- Log in to comment
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.