EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?

Create issue
Issue #145 closed
Bruno Mundim created an issue

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)

  1. Frank Löffler
    • removed 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.

  2. Roland Haas
    • 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.

  3. Frank Löffler
    • 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.

  4. Erik Schnetter
    • 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.

  5. Frank Löffler
    • 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.

  6. Log in to comment