As long as current behaviour isn't affected I see no problem. On 09/28/2018 09:43 AM, Fotis Georgatos wrote: > 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 <victor.hola...@cscs.ch> >> 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 >> victor.hola...@cscs.ch | Phone +41 91 610 82 65 >> >> On 22.08.18, 16:37, "easybuild-requ...@lists.ugent.be on behalf of Alvarez, >> Damian" <easybuild-requ...@lists.ugent.be on behalf of >> d.alva...@fz-juelich.de> 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 >> >> ------------------------------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------------------------ >> >> >>
-- Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden Internet: a...@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14 Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se
