Directory: /branches/PYSIM_2010/mdb/optionlists/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 16 Mar 2011, at 19:51, Frank Loeffler wrote:

Hi,

On Wed, Mar 16, 2011 at 05:27:57PM +0100, Ian Hinder wrote:

...

What is the reason for requiring the Fortran and C++ bindings to be present in everyones' HDF5 library?

They are not required for everyone. I only changed the option list I use for my laptop (and others also might use for Debian systems) to build the HDF5 library within Cactus. You are free to use another option list, but without this the Einstein Toolkit will not build, as it (still) depends on the Fortran interface of HDF5.

I'm not talking about your commit - it was only your commit which reminded me of the issue. I'm talking about Erik's commit to ExternalLibraries/HDF5 from a while back:

r17 | eschnett | 2010-09-11 01:18:38 +0200 (Sat, 11 Sep 2010) | 4 lines Enable C++ and Fortran support. Do not enable Fortran support if there is no Fortran 90 compiler available.

This commit not only enables C++ and Fortran support, it makes it mandatory in any HDF5 installation used. I am arguing that since it is not needed by all people, it shouldn't be made mandatory.

One option would be to detect if the HDF5 installation chosen has these features, and if so, to link the required libraries in the HDF5 thorn. In that case, a thorn which needed, e.g., the C++ HDF5 bindings would give an error when it tried to include the header file.

Whether these are needed or not is dependent on what thorns are present in the thornlist. Could we define new capabilities HDF5_CPP and HDF5_FORTRAN which are then "required" by those thorns that need them? Then the HDF5 thorn could detect if any thorns needed them and give an error early on?

An alternative would be to introduce two additional thorns, HDF5Fortran and HDF5CPP, which are each responsible for adding the appropriate libraries to HDF5_LIBS. I don't like this solution though.

- -- Ian Hinder ian.hinder@aei.mpg.de

Hello all,

On Wed, Mar 16, 2011 at 08:08:34PM +0100, Ian Hinder wrote:

...

An alternative would be to introduce two additional thorns, HDF5Fortran and HDF5CPP, which are each responsible for adding the appropriate libraries to HDF5_LIBS. I don't like this solution though.

I don't think we need to go that far. As far as I know the only tool using the c++ interface is the visit reader, and Christian agreed to rewrite it to use the C interface instead - and more related to Cactus itself EOS_Omni table reader, which uses the Fortran interface. I changed a similar routine in another code from using fortran to C, and someone (Roland?) already did that once for EOS_Omni.

I wrote C wrappers for the HDF5 functions (ie H5Dread mostly) that EOS_Omni uses (see https://trac.einsteintoolkit.org/ticket/145). They are not what you would call portable routines, but they try to at least fail loudly if their assumptions are violated (namely that any HDF5 handle returned fits in a CCTK_INT). The reason for not rewriting the actual routines that uses HDF5 was that that routine also uses Fortran 90's "allocate" to allocate an "allocatable" array (alltables in the module eos_module). Since I don't know how to do this allocation in C, I would have had to write at least two routines: * a Fortran one that does the allocate and returns a pointer to it * a C one to read in all the hdf5 datasets, call the Fortran routine with the sizes read from the file, and fill in the newly allocated table.

Yours, Roland

On Wed, Mar 16, 2011 at 3:08 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 16 Mar 2011, at 19:51, Frank Loeffler wrote:

...

Hi,

On Wed, Mar 16, 2011 at 05:27:57PM +0100, Ian Hinder wrote:

...

What is the reason for requiring the Fortran and C++ bindings to be present in everyones' HDF5 library?

They are not required for everyone. I only changed the option list I use for my laptop (and others also might use for Debian systems) to build the HDF5 library within Cactus. You are free to use another option list, but without this the Einstein Toolkit will not build, as it (still) depends on the Fortran interface of HDF5.

I'm not talking about your commit - it was only your commit which reminded me of the issue.  I'm talking about Erik's commit to ExternalLibraries/HDF5 from a while back:

r17 | eschnett | 2010-09-11 01:18:38 +0200 (Sat, 11 Sep 2010) | 4 lines        Enable C++ and Fortran support.        Do not enable Fortran support if there is no Fortran 90 compiler available.

This commit not only enables C++ and Fortran support, it makes it mandatory in any HDF5 installation used.  I am arguing that since it is not needed by all people, it shouldn't be made mandatory.

The HDF5 library is one of the easiest and most robust libraries to build. Newer versions (1.8.5, 1.8.6) have performance improvements, in particular for HPC systems and Lustre file systems. The HDF5 libraries available by default are usually older versions lacking these improvements. I don't know how much these improvements are worth in practice, but I know the people involved in implementing many of them, and (quite unfortunately) before this recent push (that started with 1.8.3 or so), the HDF5 group was not able to invest much manpower into HPC performance. I therefore assume that it makes currently sense to build HDF5 ourselves (either with Cactus or manually) on our production systems.

C++ support in HDF5 is not maintained, and we should move away from it. Fortran support is available on most systems because many people use it (which probably doesn't help you in your particular case).

-erik