Re: [easybuild] fixed-installdir-naming-scheme
Hello
Le 16.12.2019 à 19:09, Åke Sandgren a écrit :
On 12/16/19 6:05 PM, Yann Sagon wrote:
My $MODULEPATH contains after loading fosscuda/2019b:
/opt/ebmodules/all/MPI/GCC/8.3.0/OpenMPI/3.1.4:/opt/ebmodules/all/Compiler/GCC/8.3.0:/opt/ebmodules/all/Compiler/GCCcore/8.3.0
For a standard HMNS loading fosscuda/2019b should show (in your case)
/opt/ebmodules/all/MPI/GCC-CUDA/8.3.0/OpenMPI/3.1.4:/opt/ebmodules/all/Compiler/GCC-CUDA/8.3.0:...
So, take a look at your modules/all/Compiler/GCC/8.3.0/CUDA/10.1.243.lua
and verify that it does extend MODULEPATH with
prepend_path("MODULEPATH",
"/opt/ebmodules/all/Compiler/GCC-CUDA/8.3.0-10.1.243")
I don't have this file (at this place).
[sagon@node025 TensorFlow] $ find /opt/ebmodules/ -name \*10.1.243\*.lua
/opt/ebmodules/all/Core/CUDA/10.1.243.lua
And this is the module loaded by fosscuda/2019b when I do module show CUDA.
If not, or if it doesn't exist, you need to make sure you're using
EasyBuild 4.1.0 and then do a rebuild.
eb gcccuda-2019b.eb fossacuda-2019b.eb --rebuild --robot
I did that, and It wasn't working. Then I removed the gcccuda-2019b.eb
and fosscuda-2019b.eb from the repositorypath and rebuild again and this
time it's working!
A previous version of fosscuda/2019b was incorrect for HMNS
I did a diff between the two fosscuda-2019b.eb files and the obvious
difference is that CUDA is the cuda for GCC instead of a plain CUDA in
the old eb file.
Many thanks for your help, it's working fine now!
Best
--
Logo UNIGE Yann Sagon
Référent HPC
Division du système et des technologies de l'information et de la
communication
Université de Genève | 24 rue Général-Dufour
Tél 022 379 77 37 | Bureau 151
www.unige.ch/stic
Re: [easybuild] fixed-installdir-naming-scheme
On 12/16/19 6:05 PM, Yann Sagon wrote:
> My $MODULEPATH contains after loading fosscuda/2019b:
>
> /opt/ebmodules/all/MPI/GCC/8.3.0/OpenMPI/3.1.4:/opt/ebmodules/all/Compiler/GCC/8.3.0:/opt/ebmodules/all/Compiler/GCCcore/8.3.0
For a standard HMNS loading fosscuda/2019b should show (in your case)
/opt/ebmodules/all/MPI/GCC-CUDA/8.3.0/OpenMPI/3.1.4:/opt/ebmodules/all/Compiler/GCC-CUDA/8.3.0:...
So, take a look at your modules/all/Compiler/GCC/8.3.0/CUDA/10.1.243.lua
and verify that it does extend MODULEPATH with
prepend_path("MODULEPATH",
"/opt/ebmodules/all/Compiler/GCC-CUDA/8.3.0-10.1.243")
If not, or if it doesn't exist, you need to make sure you're using
EasyBuild 4.1.0 and then do a rebuild.
eb gcccuda-2019b.eb fossacuda-2019b.eb --rebuild --robot
A previous version of fosscuda/2019b was incorrect for HMNS
--
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
Re: [easybuild] fixed-installdir-naming-scheme
Hello Le 16.12.2019 à 17:41, Mikael Öhman a écrit : Hi Yann, This option only affects the install directory of the *software*, modules are unaffected. So, the completely unrelated problem is that you have not yet loaded in your toolchains before trying to load a software. Nop, it was loaded sorry to not have shown it. Remember that there are (can be) several different "SciPy-bundle/2019.10-Python-3.7.4" depending on what compilers/math kernel libraries/mpi libraries you compile it for. Yes I know:) Loading the toolchains, in this case GCC-CUDA/8.3.0 + OpenMPI/3.1.4 (or "gompic/2019b" or "fosscuda/2019b" for short) extends your modulepath to include /opt/ebsofts/MPI/GCC-CUDA/8.3.0-10.1.243/OpenMPI/3.1.4/. My $MODULEPATH contains after loading fosscuda/2019b: /opt/ebmodules/all/MPI/GCC/8.3.0/OpenMPI/3.1.4:/opt/ebmodules/all/Compiler/GCC/8.3.0:/opt/ebmodules/all/Compiler/GCCcore/8.3.0 and the SciPy-budle module is installed here: /opt/ebmodules/all/MPI/GCC-CUDA/8.3.0-10.1.243/OpenMPI/3.1.4/SciPy-bundle/2019.10-Python-3.7.4.lua And this is not part of my $MODULEPATH. Were you talking about another variable? Best
Re: [easybuild] fixed-installdir-naming-scheme
Hi Yann, This option only affects the install directory of the *software*, modules are unaffected. So, the completely unrelated problem is that you have not yet loaded in your toolchains before trying to load a software. Remember that there are (can be) several different "SciPy-bundle/2019.10-Python-3.7.4" depending on what compilers/math kernel libraries/mpi libraries you compile it for. Loading the toolchains, in this case GCC-CUDA/8.3.0 + OpenMPI/3.1.4 (or "gompic/2019b" or "fosscuda/2019b" for short) extends your modulepath to include /opt/ebsofts/MPI/GCC-CUDA/8.3.0-10.1.243/OpenMPI/3.1.4/. Anything that's built with a toolchain is placed in a toolchain. Core contains some bootstrapping things needed to get the initial compilers up and running, and typically binary distributions of commercial tools, which aren't compiled. Best regards, Mikael On Mon, Dec 16, 2019 at 5:08 PM Yann Sagon wrote: > Dear list, > > I'm sorry to bother you again, but it's still not very clear for me if I > should turn on or off this option. > > I'm now using EB 4.1.0. When I went from 3.9.x to 4.0.x I didn't changed > this option, thus I had it set to true by default. It seems it was > working fine. > > I'm using HierarchicalMNS. I must say it's fine for me if the install > directory doesn't match the hierarchy of the modules. So if I understand > well, I can just let this option > > to "True" and don't care that the modules are mixed as it works. > > Now my software are installed in /opt/ebsofts/ and my modules to > /opt/ebmodules > > I compiled SciPy-bundle/2019.10-Python-3.7.4 for fosscuda/2019b with > fixed-installdir-naming-scheme=0 > > my module is here: > > /opt/ebmodules/all/MPI/GCC-CUDA/8.3.0-10.1.243/OpenMPI/3.1.4/SciPy-bundle/2019.10-Python-3.7.4.lua > > and the software is here: > > /opt/ebsofts/MPI/GCC-CUDA/8.3.0-10.1.243/OpenMPI/3.1.4/SciPy-bundle/2019.10-Python-3.7.4 > > But i'm unable to load it: > > module --debug=1 --ignore-cache load SciPy-bundle/2019.10-Python-3.7.4 > > [...] > > Lmod has detected the following error: The following module(s) are > unknown: "SciPy-bundle/2019.10-Python-3.7.4" > > Is this related or is this an issue with my $MODULEPATH? Right now, it > contains /opt/ebmodules/all/Core. > > I'm not sure I understand why some modules are in Core and other in MPI? > > Thanks for the clarification. > > Best > > >
