[Einstein Toolkit] #1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no".
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". Nothing within the toolkit or Cactus still uses these interfaces and system wide installed libraries might not come with it, leading to link failures.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
The defaults for these options are currently still "yes". Indeed, the default system versions of HDF5 typically do not have C++ or HDF5 support. In HDF5 revision 91, Frank enabled something more, and this might be responsible for a link failure I am getting with MacPorts:
{{{ User: knarf Date: 2014/07/03 03:04 PM
Modified: /trunk/ configure.sh
Log: enable the full fortran interface when asked for it (fortran is enabled by default, when build) }}}
This reminded me of this ticket. Does anything in the toolkit now require the C++ and/or Fortran interfaces to HDF5? I think maybe something related to reading EOS tables?
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
I don't think there is. The ET compiles with both options set to 'no', as in the debian.cfg simfactory configuration.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
On the other hand - it would be good to also fix the link error in case the Fortran interface is built - regardless of this being default or not.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by hinder):
* status: new => confirmed
Comment:
I'm not sure what caused my link error, but updating macports and installing the C++/Fortran variant of the port fixed the problem. If you ask for C++ and Fortran in your optionlist, but your HDF5 installation doesn't have them, a link error seems reasonable.
I just spoke with David Radice, and he informs me that while the ET does not require the Fortran HDF5 bindings, there are many Cactus users with codes which are not part of the ET which do require these bindings. If we disable them by default, they will have to use customised optionlists, which will likely annoy them, so I don't want to do that. The C++ bindings are not used, to his knowledge, but if we are going to include the fortran ones, we may as well also require the C++ ones.
I think the most correct solution would be for a thorn to declare in its configuration.ccl file not only that it needs HDF5, but also that it needs HDF5 with fortran. i.e. "variants" for configuration dependencies. This is too much work to add, so we should find a compromise.
At the moment, the HDF5 thorn will only automatically use an HDF5 installation that has the libraries needed. However, if the user specifies HDF5_DIR, but that location doesn't have the bindings, the error comes very late, i.e. at link time. So we could add a check in the configuration script that the libraries exist there. This logic is essentially the same as that used in the probing code, so should be refactored into a common function.
In summary, my proposal is that the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN remain "yes", but an additional check is added to the HDF5 configure script in the case that HDF5_DIR is set by the user that the required libraries actually exist in that location. I have no immediate plans to do this, as it is a low priority, and only affects "advanced" users who manually set HDF5_DIR, and the resulting error message fairly well reflects the actual problem; the only issue is that it is detected late.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
A related issue: the following optionlists in simfactory set HDF5_ENABLE_FORTRAN and HDF5_ENABLE_CXX to no: debian-*, fionn, raspbian, ubuntu. It seems that this makes the simfactory optionlists inconsistent, and reflects the personal needs of the users who created those optionlists. If we decide that the HDF5 thorn by default provides the Fortran and C++ bindings, then I would like the simfactory configurations of the machines to reflect that. This will have the side-effect of requiring HDF5 to be built by Cactus on those machines. Ideally, a user would be able to override such variables in their defs.local.ini file, but I don't know how to do that in simfactory. It would be good to have an option "cactusoptions = " which could be set to options to add to the optionlist.
I am thinking of new users who try to use the toolkit with codes that require Fortran bindings, and get mysterious build failures on laptops or workstations running debian or ubuntu because the default optionlists in simfactory for those operating systems are different to all others. I think it would be better for Cactus to just build the required HDF5 in that case.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
Thinking about this some more, maybe it's not so hard to make all this work properly. Could we separate out the Fortran features from the HDF5 capability, and introduce a new optional HDF5Fortran capability? Then thorns that need fortran support would require this capability, and the HDF5 configure script would then make sure that it was available. Then users who don't need fortran support in hdf5 would be able to use system versions, and users who did need it would be able to use standard optionlists, as it would be compiled automatically by Cactus.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
One way to make this work would be to have an HDF5Fortran thorn which just provided an HDF5Fortran capability which ran a script which set HDF5_ENABLE_FORTRAN=yes. The HDF5 thorn would then have a optional requirement on this thorn, such that if HDF5Fortran were included in the thornlist, it would be configured before HDF5, and would set the HDF5_ENABLE_FORTRAN variable. Then, when HDF5 configures itself, it knows that fortran support is needed. Thorns which needed to use HDF5 fortran would then require the HDF5Fortran capability.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
This scheme would not work. Any change to the thorn list would require then reconfiguring the build, to see whether HDF5 needs to be rebuilt with Fortran support now enabled or disabled.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
Are you sure? This all happens at the thorn configuration stage. Isn't this independent of the Cactus configuration stage? A change to the thornlist already requires that the CST and the thorn configuration scripts be rerun. How would my proposed scheme be any different?
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
Replying to [comment:5 hinder]:
I am thinking of new users who try to use the toolkit with codes that
require Fortran bindings, and get mysterious build failures on laptops or workstations running debian or ubuntu because the default optionlists in simfactory for those operating systems are different to all others. I think it would be better for Cactus to just build the required HDF5 in that case.
A new user that uses other codes requiring Fortran HDF5 probably already has an installation featuring it - and if not they could be expected to set that variable I believe. The benefit of not requiring the additional interfaces by default is that, as has been said, most system libraries don't provide them - and requiring them would essentially build the bundled HDF5 and not use the system libraries - which is totally unnecessary for the ET. HDF5 is one of the libraries that tend to need a lot of build time, only dwarfed by boost.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
"other codes" would be Cactus codes, e.g. Whisky or the Zelmani GRHydro branch. New users might be compiling Cactus for the first time with these codes included in the thornlist, and they wouldn't have the required HDF5 support in their system libraries. I agree with what you say about it being a pain to have to build HDF5 each time. It would be good to have a workaround for that.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
With "other codes" I meant "unrelated codes". I agree that there should be a solution for actual Cactus thorns that do require these HDF5 interfaces, even if not in the ET. The simfactory option lists are, or at least should be, independent of the ET. On the other hand - I really would like to spare new users to compile HDF5 if they don't need it.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
To further the discussion: Please list the thorns that require Fortran HDF5. These thorns may be part of the ET or not -- I just want to see how many there are and who uses them.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by dradice@…):
In the Whisky/THC codes, we have two thorns that need Fortran HDF5: one dealing with nuclear EOS and one dealing with neutrino leakage. Both were written by Filippo Galeazzi and are not public.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
Roland says he knows of no other thorns.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
Replying to [comment:5 hinder]:
A related issue: the following optionlists in simfactory set HDF5_ENABLE_FORTRAN and HDF5_ENABLE_CXX to no: debian-*, fionn, raspbian, ubuntu. It seems that this makes the simfactory optionlists inconsistent, and reflects the personal needs of the users who created
It's not just personal taste but the fact there are no thorns in the ET that need those capabilities and that the system provided HDF5 on these distributions does not (or at least not always, since eg the Debian version of petsc requires parallel-hdf5 with conflicts with C++) provide C++ bindings. So the option list makes it more likely that users can build the Einstein Toolkit uses system provided packages by requiring as little as possible (namely only the C interface).
I have not heard of anyone having trouble with them when using HDF5. The debian and ubuntu option lists are also regularly (well once a release...) tested by me. Please think hard before you change them to have uniformity (thank you for opening a ticket for this). I my opinion, which may well differ from what we will do in the end, the situation is not so different from cluster option lists where we also do not control if the C++ or Fortran interface are supported.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
We should strive for uniformity in the default option lists. While different maintainers have different preferences, we should come to an agreement as to how the ET should behave. Us experts can easily tweak everything, so this should be geared towards newcomers on the respective machines.
So far, the arguments (relevant for non-experts) are: (1) make Fortran thorns that use HDF5 work (2) reduce build time
Both seem important. Both also seems somewhat minor, as (1) does not seem to affect too many people, and (2) does not affect correctness. In the absence of other arguments, we should weigh these two. So --
What is the difference in build time on a "regular" laptop, from scratch, with optimizations, for a full ET build with and without HDF5, with otherwise reasonable options (make -j4 or whatever appropriate)?
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
For my workstation (from scratch, 'sim build', using 'make -j 16'): {{{ - using the current debian.cfg: 4m39.713s - building HDF5 as well : 6m54.220s }}}
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by barry.wardell):
In my experience the C++ bindings are pretty worthless. The last time I checked they were barely maintained and hadn't been updated to take advantage of improvements from new releases. It is straightforward to use the C API in C++ code and I get the impression most people implement their own C++ wrapper on top of that rather than using the C++ bindings. Given this, and the fact that the C++ bindings are disabled by default in most distributions, plus the conflict with, e.g. parallel support, makes a strong case for not having them as a requirement.
It sounds like there is a stronger case for the fortran bindings. At the same time it seems unfortunate to require HDF5 to be built (since most system packages have not enabled Fortran bindings) when it's not required, just in case someone has a private thorn which uses the Fortran bindings.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
Erik, please could you reply to comment:9? If this, or something else, can be made to work, then we have the best for everyone.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
Frank: What part of HDF5 was built? Does this improve if only the Fortran interface is built, and not the C++ interface?
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
Ian: True. Still, I don't like the idea that adding or removing a thorn would potentially re-build the HDF5 library and all thorns that depend on it.
We can't make things more and more complex to cater to all possible wishes that people have. At some point, there's just a cost that has to be paid. In Frank's example, the cost is 140 seconds for a full build, which is a rare occasion.
For example, MacPorts provides HDF5 with Fortran bindings if the +Fortran variant is chosen; Ubuntu provides Fortran bindings by default, etc. I also assume that most people only install HDF5 on their laptops/workstations because the ET install instructions say so. Couldn't we just ask for the Fortran bindings as well? Which systems don't provide a system HDF5 with Fortran?
Fortran is an important language for the ET, and HDF5 is the file format we want to advertise over ASCII or pure binary files. Thus we should make it easy to read/write HDF5 from Fortran.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
Replying to [comment:22 eschnett]:
In Frank's example, the cost is 140 seconds for a full build, which is a
rare occasion.
140 seconds does not sound that much, but that is on a 16 core workstation. If looked at it in another light, it is a 50% increase in build time for the whole ET.
For example, MacPorts provides HDF5 with Fortran bindings if the
+Fortran variant is chosen; Ubuntu provides Fortran bindings by default, etc. I also assume that most people only install HDF5 on their laptops/workstations because the ET install instructions say so. Couldn't we just ask for the Fortran bindings as well? Which systems don't provide a system HDF5 with Fortran?
Actually, the Debian hdf5 packages also support Fortran (now, they didn't use to). The Cactus build triggered because of the missing C++ interface. If the latter requirement is dropped, including Fortran should be good there and does in fact use the system libraries.
So, I think we arrived at a viable solution for the default options in simfactory: requiring HDF5 interfaces for Fortran, but not C++ - any objections?
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
+1
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
Replying to [comment:23 knarf]:
So, I think we arrived at a viable solution for the default options in
simfactory: requiring HDF5 interfaces for Fortran, but not C++ - any objections?
Having said that - what I meant was that this combination would be the default set in the HDF5 thorn (Fortran: yes, C++: no). Any optionlist that wants something different would need to set it as such.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
I would remove support for the C++ bindings from thorn HDF5, unless it's easy to keep it.
I would modify all (or most) option lists to neither require nor activate this.
The goal is to reduce confusion for users.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
It would be easy to keep C++ support if the option was set. I would just set the default to 'no'.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
Kepping F90 and C support but dropping building/supplying C++ libs by default is fine with me. That would have been my suggestion but I wanted to check what each machine ini file provides, the checking never happened due to lack of time.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
This has now been done in HDF5 and simfactory.
#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: fixed | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):
* status: confirmed => closed * resolution: => fixed
trac@lists.einsteintoolkit.org
-
Einstein Toolkit