Hello Damian, Victor et al, I had missed this one, this is a very interesting offer! Indeed, it is very sensible, too.
It will come with some footnotes attached, but it can also make some situations far more manageable. It would also make life easier with some software, esp. vendor provided, case in point: integrating MPI stacks with MATLAB (mpich compatible). F. > On 22 Aug 2018, at 6:00 PM, Holanda Rusu Victor <[email protected]> > wrote: > > Dear Damian, > > I think that this is a very good approach. > In principle, it should work for MPI implementations that are part of the > MPICH ABI initiative (https://www.mpich.org/abi/) > > We do make use of this ABI compatibility for the container usage at Piz Daint > (https://user.cscs.ch/tools/containers/advanced_shifter/#native-mpi-support) > > > Best wishes, > > CSCS Swiss National Supercomputing Centre > Victor Holanda | Computational Scientist > ETH/CSCS | Via Trevano 131 | 6900 Lugano | Switzerland > [email protected] | Phone +41 91 610 82 65 > > On 22.08.18, 16:37, "[email protected] on behalf of Alvarez, > Damian" <[email protected] on behalf of > [email protected]> wrote: > > Dear EasyBuilders and lmod users, > > I have a question for the community. Currently EasyBuild supports to > deploy its software stack in a hierarchical manner, as intended and supported > by lmod (ie: load compiler, that expands $MODULEPATH and the MPIs become > visible, load an MPI, which expands $MODULEPATH again). > > There is a very significant number of MPIs that are ABI compatible (MPICH, > MVAPICH, Intel MPI, ParaStationMPI and possibly 1 or 2 more). I don't know if > OpenMPI-based MPI runtimes are also ABI compatible, but I would guess there > is a big chance that they are. > > My question is how would you feel about expanding the MPI's $MODULEPATH > based on ABI compatibility, rather than MPI_vendor/version. That way one > could offer many MPIs without needing to mirror the whole SW stack in all MPI > branches. That could simplify SW management significantly. > > Caveats I can think of are: > -One would have to be careful regarding which MPI is used to compile the > stack. MPI compiler wrappers are different, and might add different compiler > and/or linker flags. > -Some MPIs, despite being ABI compatible, might offer different > capabilities (eg: CUDA-awareness). I guess in these cases it makes sense to > try to ensure that loading packages that depend in particular MPI > capabilities, actually load the correct MPI runtime as a dependency, instead > of making vague assumptions like "the correct MPI is already loaded because > otherwise the package won't be visible in the environment". > > Similarly, one could think of a similar approach for compilers, to allow > drop-in compiler replacements. Let's say icc 2018.2 is used to compile a > given branch of the hierarchy. If that compiler has a bug that is fixed in > 2018.3, right now the whole SW stack needs to be recompiled in a separate > branch of the hierarchy. However, with a drop-in replacement one could > install the latest version of the compiler but still reuse the hierarchy > compiled with 2018.2. Needless to say, this needs to be done carefully. > However, the possibility seems interesting. > > Am I missing something? How do you feel about this? > > Best, > Damian > > -- > Dr. Damian Alvarez > Juelich Supercomputing Centre > Forschungszentrum Juelich GmbH > 52425 Juelich, Germany > > > > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > > >
