Re: [opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
Stefan Brüns writes:
Several programs will end up with implicitly linking to both versions, as libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is vtk.
This would be a nightmare. As I've stated elsewhere already, I believe it would be better if packages that are used by the 'naive' user - and especially their dependencies - should stay away from using any MPI. I don't see the benefit of MPI if you do not specifically set it up for your task. I will have to look at vtk - tomorrow probably.
As both libraries (libmpi.so.12 and libmpi.so.20) export the same symbols for large parts, this is mayhem waiting to happen.
Yes! I seem to recall that there are tricks that can be done with linker flags - but I'm not even sure if they would help in this case.
For SLE, different MPI versions/implementations are supported using the HPC modules, but for Leap/TW, we should obviously stick with *one* single canonical version.
For Leap we have the same HPC packages available as for SLE. However, these are specifically labled '-hpc' and need to be picked explicitly. They require the use of environment modules - but this should not be a problem as anyone using them will have made a consious choice to use these packages.
Question now, which version to choose?
Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], and is not supported by some software packages [2].
Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x?
Besides the fact that it is unmaintained? We do not provide or support it any more on SLE-15. Right now, openmpi2 is supported there, meaning that all openmpi2 packages on Leap 15(.0) will have the benefit of receiving all the bug fixes we add to SLE.
I have opened a bug report: https://bugzilla.opensuse.org/show_bug.cgi? id=1118861
Thanks! Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org
On Mittwoch, 2. Januar 2019 22:36:52 CET Egbert Eich wrote:
Stefan Brüns writes:
Several programs will end up with implicitly linking to both versions, as libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is vtk.
This would be a nightmare. As I've stated elsewhere already, I believe it would be better if packages that are used by the 'naive' user - and especially their dependencies - should stay away from using any MPI. I don't see the benefit of MPI if you do not specifically set it up for your task. I will have to look at vtk - tomorrow probably.
The "serial" flavor, both in science and Factory, is ok now. The openmpi(1) flavor is somewhat broken, as the dependency set for both openmpi1 and openmpi2 is imcomplete: Only available as openmpi1: - libnetcdf-openmpi, python3-mpi4py Only available as openmpi2: - boost_mpi So we have to fixup the dependencies first. I have converted vtk to a multibuild package, see https://build.opensuse.org/ package/show/home:StefanBruens:branches:science/vtk [...]
Question now, which version to choose?
Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], and is not supported by some software packages [2].
Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x?
Besides the fact that it is unmaintained? We do not provide or support it any more on SLE-15. Right now, openmpi2 is supported there, meaning that all openmpi2 packages on Leap 15(.0) will have the benefit of receiving all the bug fixes we add to SLE.
As openmpi2 is seems to available on all supported platforms (even PPC64BE since 2.1.4, science has 2.1.5), it should be a good default for everything not buildable with multiple flavors - probably only python. For vtk, this would mean adding an openmpi2 flavor to netcdf, and switching mpi4py to openmpi2. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
participants (2)
-
Egbert Eich -
Stefan Brüns