Module Files¶
In this tutorial, we'll introduce a few concepts that are fundamental to the generation of module files with Spack, and we'll guide you through the customization of both module files content and their layout on disk. In the end you should have a clear understanding of:
What are module files and how they work
How Spack generates them
Which commands are available to ease their maintenance
How it is possible to customize them in all aspects
Modules at a glance¶
Let's start by summarizing what module files are and how you can use them to modify your environment. The idea is to give enough information so that people without any previous exposure to them will be able to follow the tutorial later on. We'll also give a high-level view of how module files are generated in Spack. If you are already familiar with these topics you can quickly skim through this section or move directly to Setup for the tutorial.
What are module files?¶
Module files are an easy way to modify your environment in a controlled manner during a shell session. In general, they contain the information needed to run an application or use a library, and they work in conjunction with a tool that interprets them. Typical module files instruct this tool to modify the environment variables when a module file is loaded:
$ module show zlib ------------------------------------------------------------------- /home/mculpo/PycharmProjects/spack/share/spack/modules/linux-ubuntu14.04-x86_64/zlib/1.2.11-gcc-7.2.0-linux-ubuntu14.04-x86_64-co2px3k: module-whatis A free, general-purpose, legally unencumbered lossless data-compression library. prepend-path MANPATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/share/man prepend-path LIBRARY_PATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/lib prepend-path LD_LIBRARY_PATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/lib prepend-path CPATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/include prepend-path PKG_CONFIG_PATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/lib/pkgconfig prepend-path CMAKE_PREFIX_PATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/ ------------------------------------------------------------------- $ echo $LD_LIBRARY_PATH $ module load zlib $ echo $LD_LIBRARY_PATH /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu14.04-x86_64/gcc-7.2.0/zlib-1.2.11-co2px3k53m76lm6tofylh2mur2hnicux/lib
and to undo the modifications when the same module file is unloaded:
$ module unload zlib $ echo $LD_LIBRARY_PATH $
Different formats exist for module files, and different tools provide various levels of support for them. Spack can natively generate:
Non-hierarchical module files written in TCL
Hierarchical module files written in Lua
and can build environment-modules
and lmod as support tools.
Which of the formats or tools best suits one's needs depends on each particular
use-case. For the sake of illustration, we'll be working on
both formats using lmod
.
参考
- Environment modules
This is the original tool that provided modules support. Its first version was coded in C in the early '90s and was later substituted by a version completely coded in TCL - the one Spack is distributing. More details on its features are given in the homepage of the project or in its github page. The tool is able to interpret the non-hierarchical TCL modulefiles written by Spack.
- Lmod
Lmod is a module system written in Lua, designed to easily handle hierarchies of module files. It's a drop-in replacement of Environment Modules and works with both of the module file formats generated by Spack. Despite being fully compatible with Environment Modules there are many features that are unique to Lmod. These features are either targeted towards safety or meant to extend the module system functionality.
How do we generate module files?¶
Before we dive into the hands-on sections it's worth spending a couple of words to explain how module files are generated by Spack. The following diagram provides a high-level view of the process:
The red dashed line above represents Spack's boundaries, the blue one Spack's dependencies 1. Module files are generated by combining:
the configuration details in
config.yaml
andmodules.yaml
the information contained in Spack packages (and processed by the module subpackage)
a set of template files
with Jinja2, an external template engine that stamps out each particular module file. As Spack serves very diverse needs this process has many points of customization, and we'll explore most of them in the next sections.
- 1
Spack vendors its dependencies! This means that Spack comes with a copy of each one of its dependencies, including
Jinja2
, and is already configured to use them.
Setup for the tutorial¶
In order to showcase the capabilities of Spack's module file generation, we need a representative set of software to work with. This set must include different flavors of the same packages installed alongside each other and some external packages.
The purpose of this setup is not to make our life harder but to demonstrate how Spack can help with similar situations, as they will happen on real HPC clusters. For instance, it's often preferable for Spack to use vendor-provided MPI implementations than to build one itself.
To keep the set of software we're dealing with manageable, we're going to uninstall everything from earlier in the tutorial.
Build a module tool¶
The first thing that we need is the module tool. In this case we
choose lmod
as it can work with both hierarchical and non-hierarchical
module file layouts.
$ bin/spack install lmod
Once the module tool is installed we need to have it available in the
current shell. As the installation directories are definitely not easy
to remember, we'll employ the command spack location
to retrieve the
lmod
prefix directly from Spack:
$ . $(spack location -i lmod)/lmod/lmod/init/bash
Now we can re-source the setup file and Spack modules will be put in our module path.
$ . share/spack/setup-env.sh
Add a new compiler¶
The second step is to build a recent compiler. On first use, Spack
scans the environment and automatically locates the compiler(s)
already available on the system. For this tutorial, however, we want
to use gcc@7.2.0
.
$ spack install gcc@7.2.0
...
Wait a long time
...
Once gcc
is installed we can use shell support to load it and make
it readily available:
$ spack load gcc@7.2.0
It may not be apparent, but the last command employed the module files
generated automatically by Spack. What happens under the hood when you use
the spack load
command is:
the spec passed as argument is translated into a module file name
the current module tool is used to load that module file
You can use this command to double check:
$ module list
Currently Loaded Modules:
1) gcc-7.2.0-gcc-5.4.0-b7smjjc
Note that the 7-digit hash at the end of the generated module may vary depending
on architecture or package version. Now that we have gcc@7.2.0
in PATH
we
can finally add it to the list of compilers known to Spack:
$ spack compiler add
==> Added 1 new compiler to /home/spack1/.spack/linux/compilers.yaml
gcc@7.2.0
==> Compilers are defined in the following files:
/home/spack1/.spack/linux/compilers.yaml
$ spack compiler list
==> Available compilers
-- clang ubuntu16.04-x86_64 -------------------------------------
clang@3.8.0-2ubuntu4 clang@3.7.1-2ubuntu2
-- gcc ubuntu16.04-x86_64 ---------------------------------------
gcc@7.2.0 gcc@5.4.0 gcc@4.7
Build the software that will be used in the tutorial¶
Finally, we should use Spack to install the packages used in the examples:
$ spack install netlib-scalapack ^openmpi ^openblas
$ spack install netlib-scalapack ^mpich ^openblas
$ spack install netlib-scalapack ^openmpi ^netlib-lapack
$ spack install netlib-scalapack ^mpich ^netlib-lapack
$ spack install py-scipy ^openblas
Non-hierarchical module files¶
If you arrived to this point you should have an environment that looks similar to:
$ module avail
----------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 -----------------------------------------------
autoconf-2.69-gcc-5.4.0-3sx2gxe libsigsegv-2.11-gcc-7.2.0-g67xpfd openssl-1.0.2o-gcc-5.4.0-b4y3w3b
autoconf-2.69-gcc-7.2.0-yb2makb libtool-2.4.6-gcc-5.4.0-o2pfwjf openssl-1.0.2o-gcc-7.2.0-cvldq3v
automake-1.16.1-gcc-5.4.0-rymw7im libtool-2.4.6-gcc-7.2.0-kt2udm6 pcre-8.42-gcc-5.4.0-gt5lgzi
automake-1.16.1-gcc-7.2.0-qoowd5q libxml2-2.9.8-gcc-5.4.0-wpexsph perl-5.26.2-gcc-5.4.0-ic2kyoa
bzip2-1.0.6-gcc-5.4.0-ufczdvs libxml2-2.9.8-gcc-7.2.0-47gf5kk perl-5.26.2-gcc-7.2.0-fdwz5yu
bzip2-1.0.6-gcc-7.2.0-mwamumj lmod-7.8-gcc-5.4.0-kmhks3p pkgconf-1.4.2-gcc-5.4.0-fovrh7a
cmake-3.12.3-gcc-7.2.0-obqgn2v lua-5.3.4-gcc-5.4.0-cpfeo2w pkgconf-1.4.2-gcc-7.2.0-yoxwmgb
curl-7.60.0-gcc-5.4.0-vzqreb2 lua-luafilesystem-1_6_3-gcc-5.4.0-alakjim py-numpy-1.15.2-gcc-7.2.0-wbwtcxf
diffutils-3.6-gcc-5.4.0-2rhuivg lua-luaposix-33.4.0-gcc-5.4.0-7wqhwoc py-scipy-1.1.0-gcc-7.2.0-d5n3cph
diffutils-3.6-gcc-7.2.0-eauxwi7 m4-1.4.18-gcc-5.4.0-suf5jtc py-setuptools-40.4.3-gcc-7.2.0-5dbwfwn
expat-2.2.5-gcc-5.4.0-emyv67q m4-1.4.18-gcc-7.2.0-wdzvagl python-2.7.15-gcc-7.2.0-ucmr2mn
findutils-4.6.0-gcc-7.2.0-ca4b7zq mpc-1.1.0-gcc-5.4.0-iuf3gc3 readline-7.0-gcc-5.4.0-nxhwrg7
gcc-7.2.0-gcc-5.4.0-b7smjjc (L) mpfr-3.1.6-gcc-5.4.0-jnt2nnp readline-7.0-gcc-7.2.0-ccruj2i
gdbm-1.14.1-gcc-5.4.0-q4fpyuo mpich-3.2.1-gcc-7.2.0-vt5xcat sqlite-3.23.1-gcc-7.2.0-5ltus3a
gdbm-1.14.1-gcc-7.2.0-zk5lhob ncurses-6.1-gcc-5.4.0-3o765ou tar-1.30-gcc-5.4.0-dk7lrpo
gettext-0.19.8.1-gcc-5.4.0-tawgous ncurses-6.1-gcc-7.2.0-xcgzqdv tcl-8.6.8-gcc-5.4.0-qhwyccy
git-2.19.1-gcc-5.4.0-p3gjnfa netlib-lapack-3.8.0-gcc-7.2.0-fj7nayd texinfo-6.5-gcc-7.2.0-cuqnfgf
gmp-6.1.2-gcc-5.4.0-qc4qcfz netlib-scalapack-2.0.2-gcc-7.2.0-67nmj7g unzip-6.0-gcc-5.4.0-ba23fbg
hwloc-1.11.9-gcc-7.2.0-gbyc65s netlib-scalapack-2.0.2-gcc-7.2.0-6jgjbyg util-macros-1.19.1-gcc-7.2.0-t62kozq
isl-0.18-gcc-5.4.0-vttqout netlib-scalapack-2.0.2-gcc-7.2.0-prgo67d xz-5.2.4-gcc-5.4.0-teneqii
libbsd-0.8.6-gcc-5.4.0-f4qkkwm netlib-scalapack-2.0.2-gcc-7.2.0-zxpt252 xz-5.2.4-gcc-7.2.0-rql5kog
libiconv-1.15-gcc-5.4.0-u2x3umv numactl-2.0.11-gcc-7.2.0-rifwktk zlib-1.2.11-gcc-5.4.0-5nus6kn
libpciaccess-0.13.5-gcc-7.2.0-riipwi2 openblas-0.3.3-gcc-7.2.0-xxoxfh4 zlib-1.2.11-gcc-7.2.0-ezuwp4p
libsigsegv-2.11-gcc-5.4.0-fypapcp openmpi-3.1.3-gcc-7.2.0-do5xfer
Where:
L: Module is loaded
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
The non-hierarchical module files that have been generated so far
follow the default rules for module generation.
Taking a look at the gcc
module you'll see, for example:
$ module show gcc-7.2.0-gcc-5.4.0-b7smjjc
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/gcc-7.2.0-gcc-5.4.0-b7smjjc:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages. ")
prepend_path("PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin")
prepend_path("MANPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/share/man")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib")
prepend_path("LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib64")
prepend_path("LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib64")
prepend_path("CPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/include")
prepend_path("CMAKE_PREFIX_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/")
setenv("CC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gcc")
setenv("CXX","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/g++")
setenv("FC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F77","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F90","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
help([[The GNU Compiler Collection includes front ends for C, C++, Objective-C,
Fortran, Ada, and Go, as well as libraries for these languages.
]])
As expected, a few environment variables representing paths will be modified by the module file according to the default prefix inspection rules.
Filter unwanted modifications to the environment¶
Now consider the case that your site has decided that CPATH
and
LIBRARY_PATH
modifications should not be present in module files. What you can
do to abide by the rules is to create a configuration file ~/.spack/modules.yaml
with the following content:
modules:
tcl:
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
Next you should regenerate all the module files:
$ spack module tcl refresh
==> You are about to regenerate tcl module files for:
-- linux-ubuntu16.04-x86_64 / gcc@5.4.0 -------------------------
3sx2gxe autoconf@2.69 b7smjjc gcc@7.2.0 f4qkkwm libbsd@0.8.6 cpfeo2w lua@5.3.4 3o765ou ncurses@6.1 dk7lrpo tar@1.30
rymw7im automake@1.16.1 q4fpyuo gdbm@1.14.1 u2x3umv libiconv@1.15 alakjim lua-luafilesystem@1_6_3 b4y3w3b openssl@1.0.2o qhwyccy tcl@8.6.8
ufczdvs bzip2@1.0.6 tawgous gettext@0.19.8.1 fypapcp libsigsegv@2.11 7wqhwoc lua-luaposix@33.4.0 gt5lgzi pcre@8.42 ba23fbg unzip@6.0
vzqreb2 curl@7.60.0 p3gjnfa git@2.19.1 o2pfwjf libtool@2.4.6 suf5jtc m4@1.4.18 ic2kyoa perl@5.26.2 teneqii xz@5.2.4
2rhuivg diffutils@3.6 qc4qcfz gmp@6.1.2 wpexsph libxml2@2.9.8 iuf3gc3 mpc@1.1.0 fovrh7a pkgconf@1.4.2 5nus6kn zlib@1.2.11
emyv67q expat@2.2.5 vttqout isl@0.18 kmhks3p lmod@7.8 jnt2nnp mpfr@3.1.6 nxhwrg7 readline@7.0
-- linux-ubuntu16.04-x86_64 / gcc@7.2.0 -------------------------
yb2makb autoconf@2.69 riipwi2 libpciaccess@0.13.5 6jgjbyg netlib-scalapack@2.0.2 fdwz5yu perl@5.26.2 cuqnfgf texinfo@6.5
qoowd5q automake@1.16.1 g67xpfd libsigsegv@2.11 zxpt252 netlib-scalapack@2.0.2 yoxwmgb pkgconf@1.4.2 t62kozq util-macros@1.19.1
mwamumj bzip2@1.0.6 kt2udm6 libtool@2.4.6 67nmj7g netlib-scalapack@2.0.2 wbwtcxf py-numpy@1.15.2 rql5kog xz@5.2.4
obqgn2v cmake@3.12.3 47gf5kk libxml2@2.9.8 prgo67d netlib-scalapack@2.0.2 d5n3cph py-scipy@1.1.0 ezuwp4p zlib@1.2.11
eauxwi7 diffutils@3.6 wdzvagl m4@1.4.18 rifwktk numactl@2.0.11 5dbwfwn py-setuptools@40.4.3
ca4b7zq findutils@4.6.0 vt5xcat mpich@3.2.1 xxoxfh4 openblas@0.3.3 ucmr2mn python@2.7.15
zk5lhob gdbm@1.14.1 xcgzqdv ncurses@6.1 do5xfer openmpi@3.1.3 ccruj2i readline@7.0
gbyc65s hwloc@1.11.9 fj7nayd netlib-lapack@3.8.0 cvldq3v openssl@1.0.2o 5ltus3a sqlite@3.23.1
==> Do you want to proceed? [y/n] y
==> Regenerating tcl module files
If you take a look now at the module for gcc
you'll see that the unwanted
paths have disappeared:
$ module show gcc-7.2.0-gcc-5.4.0-b7smjjc
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/gcc-7.2.0-gcc-5.4.0-b7smjjc:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages. ")
prepend_path("PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin")
prepend_path("MANPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/share/man")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib64")
prepend_path("CMAKE_PREFIX_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/")
setenv("CC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gcc")
setenv("CXX","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/g++")
setenv("FC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F77","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F90","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
help([[The GNU Compiler Collection includes front ends for C, C++, Objective-C,
Fortran, Ada, and Go, as well as libraries for these languages.
]])
Prevent some module files from being generated¶
Another common request at many sites is to avoid exposing software that
is only needed as an intermediate step when building a newer stack.
Let's try to prevent the generation of
module files for anything that is compiled with gcc@5.4.0
(the OS provided compiler).
To do this you should add a blacklist
keyword to ~/.spack/modules.yaml
:
modules:
tcl:
blacklist:
- '%gcc@5.4.0'
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
and regenerate the module files:
This time it is convenient to pass the option --delete-tree
to the command that
regenerates the module files to instruct it to delete the existing tree and regenerate
a new one instead of overwriting the files in the existing directory.
$ spack module tcl refresh --delete-tree
==> You are about to regenerate tcl module files for:
-- linux-ubuntu16.04-x86_64 / gcc@5.4.0 -------------------------
3sx2gxe autoconf@2.69 b7smjjc gcc@7.2.0 f4qkkwm libbsd@0.8.6 cpfeo2w lua@5.3.4 3o765ou ncurses@6.1 dk7lrpo tar@1.30
rymw7im automake@1.16.1 q4fpyuo gdbm@1.14.1 u2x3umv libiconv@1.15 alakjim lua-luafilesystem@1_6_3 b4y3w3b openssl@1.0.2o qhwyccy tcl@8.6.8
ufczdvs bzip2@1.0.6 tawgous gettext@0.19.8.1 fypapcp libsigsegv@2.11 7wqhwoc lua-luaposix@33.4.0 gt5lgzi pcre@8.42 ba23fbg unzip@6.0
vzqreb2 curl@7.60.0 p3gjnfa git@2.19.1 o2pfwjf libtool@2.4.6 suf5jtc m4@1.4.18 ic2kyoa perl@5.26.2 teneqii xz@5.2.4
2rhuivg diffutils@3.6 qc4qcfz gmp@6.1.2 wpexsph libxml2@2.9.8 iuf3gc3 mpc@1.1.0 fovrh7a pkgconf@1.4.2 5nus6kn zlib@1.2.11
emyv67q expat@2.2.5 vttqout isl@0.18 kmhks3p lmod@7.8 jnt2nnp mpfr@3.1.6 nxhwrg7 readline@7.0
-- linux-ubuntu16.04-x86_64 / gcc@7.2.0 -------------------------
yb2makb autoconf@2.69 riipwi2 libpciaccess@0.13.5 6jgjbyg netlib-scalapack@2.0.2 fdwz5yu perl@5.26.2 cuqnfgf texinfo@6.5
qoowd5q automake@1.16.1 g67xpfd libsigsegv@2.11 zxpt252 netlib-scalapack@2.0.2 yoxwmgb pkgconf@1.4.2 t62kozq util-macros@1.19.1
mwamumj bzip2@1.0.6 kt2udm6 libtool@2.4.6 67nmj7g netlib-scalapack@2.0.2 wbwtcxf py-numpy@1.15.2 rql5kog xz@5.2.4
obqgn2v cmake@3.12.3 47gf5kk libxml2@2.9.8 prgo67d netlib-scalapack@2.0.2 d5n3cph py-scipy@1.1.0 ezuwp4p zlib@1.2.11
eauxwi7 diffutils@3.6 wdzvagl m4@1.4.18 rifwktk numactl@2.0.11 5dbwfwn py-setuptools@40.4.3
ca4b7zq findutils@4.6.0 vt5xcat mpich@3.2.1 xxoxfh4 openblas@0.3.3 ucmr2mn python@2.7.15
zk5lhob gdbm@1.14.1 xcgzqdv ncurses@6.1 do5xfer openmpi@3.1.3 ccruj2i readline@7.0
gbyc65s hwloc@1.11.9 fj7nayd netlib-lapack@3.8.0 cvldq3v openssl@1.0.2o 5ltus3a sqlite@3.23.1
==> Do you want to proceed? [y/n] y
==> Regenerating tcl module files
$ module avail
----------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 -----------------------------------------------
autoconf-2.69-gcc-7.2.0-yb2makb m4-1.4.18-gcc-7.2.0-wdzvagl perl-5.26.2-gcc-7.2.0-fdwz5yu
automake-1.16.1-gcc-7.2.0-qoowd5q mpich-3.2.1-gcc-7.2.0-vt5xcat pkgconf-1.4.2-gcc-7.2.0-yoxwmgb
bzip2-1.0.6-gcc-7.2.0-mwamumj ncurses-6.1-gcc-7.2.0-xcgzqdv py-numpy-1.15.2-gcc-7.2.0-wbwtcxf
cmake-3.12.3-gcc-7.2.0-obqgn2v netlib-lapack-3.8.0-gcc-7.2.0-fj7nayd py-scipy-1.1.0-gcc-7.2.0-d5n3cph
diffutils-3.6-gcc-7.2.0-eauxwi7 netlib-scalapack-2.0.2-gcc-7.2.0-67nmj7g py-setuptools-40.4.3-gcc-7.2.0-5dbwfwn
findutils-4.6.0-gcc-7.2.0-ca4b7zq netlib-scalapack-2.0.2-gcc-7.2.0-6jgjbyg python-2.7.15-gcc-7.2.0-ucmr2mn
gdbm-1.14.1-gcc-7.2.0-zk5lhob netlib-scalapack-2.0.2-gcc-7.2.0-prgo67d readline-7.0-gcc-7.2.0-ccruj2i
hwloc-1.11.9-gcc-7.2.0-gbyc65s netlib-scalapack-2.0.2-gcc-7.2.0-zxpt252 sqlite-3.23.1-gcc-7.2.0-5ltus3a
libpciaccess-0.13.5-gcc-7.2.0-riipwi2 numactl-2.0.11-gcc-7.2.0-rifwktk texinfo-6.5-gcc-7.2.0-cuqnfgf
libsigsegv-2.11-gcc-7.2.0-g67xpfd openblas-0.3.3-gcc-7.2.0-xxoxfh4 util-macros-1.19.1-gcc-7.2.0-t62kozq
libtool-2.4.6-gcc-7.2.0-kt2udm6 openmpi-3.1.3-gcc-7.2.0-do5xfer xz-5.2.4-gcc-7.2.0-rql5kog
libxml2-2.9.8-gcc-7.2.0-47gf5kk openssl-1.0.2o-gcc-7.2.0-cvldq3v zlib-1.2.11-gcc-7.2.0-ezuwp4p
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
If you look closely you'll see though that we went too far in blacklisting modules:
the module for gcc@7.2.0
disappeared as it was bootstrapped with gcc@5.4.0
. To specify
exceptions to the blacklist rules you can use whitelist
:
modules:
tcl:
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
whitelist
rules always have precedence over blacklist
rules. If you regenerate the modules again:
$ spack module tcl refresh -y
==> Regenerating tcl module files
you'll see that now the module for gcc@7.2.0
has reappeared:
$ module avail gcc-7.2.0-gcc-5.4.0-b7smjjc
-------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 ---------------------------------------------
gcc-7.2.0-gcc-5.4.0-b7smjjc
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
An additional possibility that you can leverage to unclutter the environment is that of preventing the generation of module files for implicitly installed packages. In this case all one needs to do is to add the following line:
modules:
tcl:
blacklist_implicits: true
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
to modules.yaml
and regenerate the module file tree as above.
Change module file naming¶
The next step in making module files more user-friendly is to
improve their naming scheme.
To reduce the length of the hash or remove it altogether you can
use the hash_length
keyword in the configuration file:
modules:
tcl:
hash_length: 0
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
If you try to regenerate the module files now you will get an error:
$ spack module tcl refresh --delete-tree -y
==> Error: Name clashes detected in module files:
file: /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/netlib-scalapack-2.0.2-gcc-7.2.0
spec: netlib-scalapack@2.0.2%gcc@7.2.0 build_type=RelWithDebInfo ~pic+shared arch=linux-ubuntu16.04-x86_64
spec: netlib-scalapack@2.0.2%gcc@7.2.0 build_type=RelWithDebInfo ~pic+shared arch=linux-ubuntu16.04-x86_64
spec: netlib-scalapack@2.0.2%gcc@7.2.0 build_type=RelWithDebInfo ~pic+shared arch=linux-ubuntu16.04-x86_64
spec: netlib-scalapack@2.0.2%gcc@7.2.0 build_type=RelWithDebInfo ~pic+shared arch=linux-ubuntu16.04-x86_64
==> Error: Operation aborted
注釈
- We try to check for errors upfront!
In Spack we check for errors upfront whenever possible, so don't worry about your module files: as a name clash was detected nothing has been changed on disk.
The problem here is that without
the hashes the four different flavors of netlib-scalapack
map to the same module file
name. We can add suffixes to differentiate them:
modules:
tcl:
hash_length: 0
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
netlib-scalapack:
suffixes:
'^openmpi': openmpi
'^mpich': mpich
As you can see it is possible to specify rules that apply only to a restricted set of packages using anonymous specs. Regenerating module files now we obtain:
$ spack module tcl refresh --delete-tree -y
==> Regenerating tcl module files
$ module avail
----------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 -----------------------------------------------
autoconf-2.69-gcc-7.2.0 m4-1.4.18-gcc-7.2.0 pkgconf-1.4.2-gcc-7.2.0
automake-1.16.1-gcc-7.2.0 mpich-3.2.1-gcc-7.2.0 py-numpy-1.15.2-gcc-7.2.0-openblas
bzip2-1.0.6-gcc-7.2.0 ncurses-6.1-gcc-7.2.0 py-scipy-1.1.0-gcc-7.2.0-openblas
cmake-3.12.3-gcc-7.2.0 netlib-lapack-3.8.0-gcc-7.2.0 py-setuptools-40.4.3-gcc-7.2.0
diffutils-3.6-gcc-7.2.0 netlib-scalapack-2.0.2-gcc-7.2.0-netlib-mpich python-2.7.15-gcc-7.2.0
findutils-4.6.0-gcc-7.2.0 netlib-scalapack-2.0.2-gcc-7.2.0-netlib-openmpi readline-7.0-gcc-7.2.0
gcc-7.2.0-gcc-5.4.0 netlib-scalapack-2.0.2-gcc-7.2.0-openblas-mpich sqlite-3.23.1-gcc-7.2.0
gdbm-1.14.1-gcc-7.2.0 netlib-scalapack-2.0.2-gcc-7.2.0-openblas-openmpi texinfo-6.5-gcc-7.2.0
hwloc-1.11.9-gcc-7.2.0 numactl-2.0.11-gcc-7.2.0 util-macros-1.19.1-gcc-7.2.0
libpciaccess-0.13.5-gcc-7.2.0 openblas-0.3.3-gcc-7.2.0 xz-5.2.4-gcc-7.2.0
libsigsegv-2.11-gcc-7.2.0 openmpi-3.1.3-gcc-7.2.0 zlib-1.2.11-gcc-7.2.0
libtool-2.4.6-gcc-7.2.0 openssl-1.0.2o-gcc-7.2.0
libxml2-2.9.8-gcc-7.2.0 perl-5.26.2-gcc-7.2.0
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
Finally we can set a naming_scheme
to prevent users from loading
modules that refer to different flavors of the same library/application:
modules:
tcl:
hash_length: 0
naming_scheme: '{name}/{version}-{compiler.name}-{compiler.version}'
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
conflict:
- '{name}'
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
netlib-scalapack:
suffixes:
'^openmpi': openmpi
'^mpich': mpich
The final result should look like:
$ spack module tcl refresh --delete-tree -y
==> Regenerating tcl module files
$ module avail
----------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 -----------------------------------------------
autoconf/2.69-gcc-7.2.0 m4/1.4.18-gcc-7.2.0 pkgconf/1.4.2-gcc-7.2.0
automake/1.16.1-gcc-7.2.0 mpich/3.2.1-gcc-7.2.0 py-numpy/1.15.2-gcc-7.2.0-openblas
bzip2/1.0.6-gcc-7.2.0 ncurses/6.1-gcc-7.2.0 py-scipy/1.1.0-gcc-7.2.0-openblas
cmake/3.12.3-gcc-7.2.0 netlib-lapack/3.8.0-gcc-7.2.0 py-setuptools/40.4.3-gcc-7.2.0
diffutils/3.6-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-netlib-mpich python/2.7.15-gcc-7.2.0
findutils/4.6.0-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-netlib-openmpi readline/7.0-gcc-7.2.0
gcc/7.2.0-gcc-5.4.0 netlib-scalapack/2.0.2-gcc-7.2.0-openblas-mpich sqlite/3.23.1-gcc-7.2.0
gdbm/1.14.1-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-openblas-openmpi (D) texinfo/6.5-gcc-7.2.0
hwloc/1.11.9-gcc-7.2.0 numactl/2.0.11-gcc-7.2.0 util-macros/1.19.1-gcc-7.2.0
libpciaccess/0.13.5-gcc-7.2.0 openblas/0.3.3-gcc-7.2.0 xz/5.2.4-gcc-7.2.0
libsigsegv/2.11-gcc-7.2.0 openmpi/3.1.3-gcc-7.2.0 zlib/1.2.11-gcc-7.2.0
libtool/2.4.6-gcc-7.2.0 openssl/1.0.2o-gcc-7.2.0
libxml2/2.9.8-gcc-7.2.0 perl/5.26.2-gcc-7.2.0
Where:
D: Default Module
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
注釈
- TCL specific directive
The directives
naming_scheme
andconflict
are TCL specific and can't be used in thelmod
section of the configuration file.
Add custom environment modifications¶
At many sites it is customary to set an environment variable in a
package's module file that points to the folder in which the package
is installed. You can achieve this with Spack by adding an
environment
directive to the configuration file:
modules:
tcl:
hash_length: 0
naming_scheme: '{name}/{version}-{compiler.name}-{compiler.version}'
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
conflict:
- '{name}'
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
netlib-scalapack:
suffixes:
'^openmpi': openmpi
'^mpich': mpich
Under the hood Spack uses the format()
API to substitute
tokens in either environment variable names or values. There are two caveats though:
The set of allowed tokens in variable names is restricted to
name
,version
,compiler
,compiler.name
,compiler.version
,architecture
Any token expanded in a variable name is made uppercase, but other than that case sensitivity is preserved
Regenerating the module files results in something like:
$ spack module tcl refresh -y
==> Regenerating tcl module files
$ module show gcc
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/gcc/7.2.0-gcc-5.4.0:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages. ")
conflict("gcc")
prepend_path("PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin")
prepend_path("MANPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/share/man")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib64")
prepend_path("CMAKE_PREFIX_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/")
setenv("CC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gcc")
setenv("CXX","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/g++")
setenv("FC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F77","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F90","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("GCC_ROOT","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs")
help([[The GNU Compiler Collection includes front ends for C, C++, Objective-C,
Fortran, Ada, and Go, as well as libraries for these languages.
]])
As you can see, the gcc
module has the environment variable GCC_ROOT
set.
Sometimes it's also useful to apply environment modifications selectively and target
only certain packages. You can, for instance set the common variables CC
, CXX
,
etc. in the gcc
module file and apply other custom modifications to the
openmpi
modules as follows:
modules:
tcl:
hash_length: 0
naming_scheme: '{name}/{version}-{compiler.name}-{compiler.version}'
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
conflict:
- '{name}'
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
gcc:
environment:
set:
CC: gcc
CXX: g++
FC: gfortran
F90: gfortran
F77: gfortran
openmpi:
environment:
set:
SLURM_MPI_TYPE: pmi2
OMPI_MCA_btl_openib_warn_default_gid_prefix: '0'
netlib-scalapack:
suffixes:
'^openmpi': openmpi
'^mpich': mpich
This time we will be more selective and regenerate only the gcc
and
openmpi
module files:
$ spack module tcl refresh -y gcc
==> Regenerating tcl module files
$ spack module tcl refresh -y openmpi
==> Regenerating tcl module files
$ module show gcc
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/gcc/7.2.0-gcc-5.4.0:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages. ")
conflict("gcc")
prepend_path("PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin")
prepend_path("MANPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/share/man")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/lib64")
prepend_path("CMAKE_PREFIX_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/")
setenv("CC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gcc")
setenv("CXX","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/g++")
setenv("FC","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F77","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("F90","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs/bin/gfortran")
setenv("GCC_ROOT","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/gcc-7.2.0-b7smjjcsmwe5u5fcsvjmonlhlzzctnfs")
setenv("CC","gcc")
setenv("CXX","g++'")
setenv("FC","gfortran")
setenv("F77","gfortran")
setenv("F90","gfortran")
help([[The GNU Compiler Collection includes front ends for C, C++, Objective-C,
Fortran, Ada, and Go, as well as libraries for these languages.
]])
$ module show openmpi
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
/home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64/openmpi/3.1.3-gcc-7.2.0:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("An open source Message Passing Interface implementation. ")
conflict("openmpi")
prepend_path("PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4/bin")
prepend_path("MANPATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4/share/man")
prepend_path("LD_LIBRARY_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4/lib")
prepend_path("PKG_CONFIG_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4/lib/pkgconfig")
prepend_path("CMAKE_PREFIX_PATH","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4/")
setenv("OPENMPI_ROOT","/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/openmpi-3.1.3-do5xfer2whhk7gc26atgs3ozr3ljbvs4")
setenv("SLURM_MPI_TYPE","pmi2")
setenv("OMPI_MCA_btl_openib_warn_default_gid_prefix","0")
help([[An open source Message Passing Interface implementation. The Open MPI
Project is an open source Message Passing Interface implementation that
is developed and maintained by a consortium of academic, research, and
industry partners. Open MPI is therefore able to combine the expertise,
technologies, and resources from all across the High Performance
Computing community in order to build the best MPI library available.
Open MPI offers advantages for system and software vendors, application
developers and computer science researchers.
]])
Autoload dependencies¶
Spack can also generate module files that contain code to load the
dependencies automatically. You can, for instance generate python
modules that load their dependencies by adding the autoload
directive and assigning it the value direct
:
modules:
tcl:
verbose: True
hash_length: 0
naming_scheme: '{name}/{version}-{compiler.name}-{compiler.version}'
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
conflict:
- '{name}'
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
gcc:
environment:
set:
CC: gcc
CXX: g++
FC: gfortran
F90: gfortran
F77: gfortran
openmpi:
environment:
set:
SLURM_MPI_TYPE: pmi2
OMPI_MCA_btl_openib_warn_default_gid_prefix: '0'
netlib-scalapack:
suffixes:
'^openmpi': openmpi
'^mpich': mpich
^python:
autoload: 'direct'
and regenerating the module files for every package that depends on python
:
root@module-file-tutorial:/# spack module tcl refresh -y ^python
==> Regenerating tcl module files
Now the py-scipy
module will be:
#%Module1.0
## Module file created by spack (https://github.com/spack/spack) on 2018-11-11 22:10:48.834221
##
## py-scipy@1.1.0%gcc@7.2.0 arch=linux-ubuntu16.04-x86_64 /d5n3cph
##
module-whatis "SciPy (pronounced 'Sigh Pie') is a Scientific Library for Python. It provides many user-friendly and efficient numerical routines such as routines for numerical integration and optimization."
proc ModulesHelp { } {
puts stderr "SciPy (pronounced "Sigh Pie") is a Scientific Library for Python. It"
puts stderr "provides many user-friendly and efficient numerical routines such as"
puts stderr "routines for numerical integration and optimization."
}
if { [ module-info mode load ] && ![ is-loaded python/2.7.15-gcc-7.2.0 ] } {
puts stderr "Autoloading python/2.7.15-gcc-7.2.0"
module load python/2.7.15-gcc-7.2.0
}
if { [ module-info mode load ] && ![ is-loaded openblas/0.3.3-gcc-7.2.0 ] } {
puts stderr "Autoloading openblas/0.3.3-gcc-7.2.0"
module load openblas/0.3.3-gcc-7.2.0
}
if { [ module-info mode load ] && ![ is-loaded py-numpy/1.15.2-gcc-7.2.0-openblas ] } {
puts stderr "Autoloading py-numpy/1.15.2-gcc-7.2.0-openblas"
module load py-numpy/1.15.2-gcc-7.2.0-openblas
}
conflict py-scipy
prepend-path LD_LIBRARY_PATH "/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/py-scipy-1.1.0-d5n3cphk2lx2v74ypwb6h7tna7vvgdyn/lib"
prepend-path CMAKE_PREFIX_PATH "/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/py-scipy-1.1.0-d5n3cphk2lx2v74ypwb6h7tna7vvgdyn/"
prepend-path PYTHONPATH "/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/py-scipy-1.1.0-d5n3cphk2lx2v74ypwb6h7tna7vvgdyn/lib/python2.7/site-packages"
setenv PY_SCIPY_ROOT "/home/spack1/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/py-scipy-1.1.0-d5n3cphk2lx2v74ypwb6h7tna7vvgdyn"
and will contain code to autoload all the dependencies:
$ module load py-scipy
Autoloading python/2.7.15-gcc-7.2.0
Autoloading openblas/0.3.3-gcc-7.2.0
Autoloading py-numpy/1.15.2-gcc-7.2.0-openblas
In case messages are unwanted during the autoload procedure, it will be
sufficient to omit the line setting verbose: True
in the configuration file above.
Hierarchical module files¶
So far we worked with non-hierarchical module files, i.e. with module files
that are all generated in the same root directory and don't attempt to
dynamically modify the MODULEPATH
. This results in a flat module structure where
all the software is visible at the same time:
$ module avail
----------------------------------------------- /home/spack1/spack/share/spack/modules/linux-ubuntu16.04-x86_64 -----------------------------------------------
autoconf/2.69-gcc-7.2.0 m4/1.4.18-gcc-7.2.0 pkgconf/1.4.2-gcc-7.2.0
automake/1.16.1-gcc-7.2.0 mpich/3.2.1-gcc-7.2.0 py-numpy/1.15.2-gcc-7.2.0-openblas (L)
bzip2/1.0.6-gcc-7.2.0 ncurses/6.1-gcc-7.2.0 py-scipy/1.1.0-gcc-7.2.0-openblas (L)
cmake/3.12.3-gcc-7.2.0 netlib-lapack/3.8.0-gcc-7.2.0 py-setuptools/40.4.3-gcc-7.2.0
diffutils/3.6-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-netlib-mpich python/2.7.15-gcc-7.2.0 (L)
findutils/4.6.0-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-netlib-openmpi readline/7.0-gcc-7.2.0
gcc/7.2.0-gcc-5.4.0 netlib-scalapack/2.0.2-gcc-7.2.0-openblas-mpich sqlite/3.23.1-gcc-7.2.0
gdbm/1.14.1-gcc-7.2.0 netlib-scalapack/2.0.2-gcc-7.2.0-openblas-openmpi (D) texinfo/6.5-gcc-7.2.0
hwloc/1.11.9-gcc-7.2.0 numactl/2.0.11-gcc-7.2.0 util-macros/1.19.1-gcc-7.2.0
libpciaccess/0.13.5-gcc-7.2.0 openblas/0.3.3-gcc-7.2.0 (L) xz/5.2.4-gcc-7.2.0
libsigsegv/2.11-gcc-7.2.0 openmpi/3.1.3-gcc-7.2.0 zlib/1.2.11-gcc-7.2.0
libtool/2.4.6-gcc-7.2.0 openssl/1.0.2o-gcc-7.2.0
libxml2/2.9.8-gcc-7.2.0 perl/5.26.2-gcc-7.2.0
Where:
L: Module is loaded
D: Default Module
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
This layout is quite simple to deploy, but you can see from the above snippet that nothing prevents users from loading incompatible sets of modules:
$ module purge
$ module load netlib-lapack/3.8.0-gcc-7.2.0 openblas/0.3.3-gcc-7.2.0
$ module list
Currently Loaded Modules:
1) netlib-lapack/3.8.0-gcc-7.2.0 2) openblas/0.3.3-gcc-7.2.0
Even if conflicts
directives are carefully placed in module files, they:
won't enforce a consistent environment, but will just report an error
need constant updates, for instance as soon as a new compiler or MPI library is installed
Hierarchical module files try to
overcome these shortcomings by showing at start-up only a restricted view of what is
available on the system: more specifically only the software that has been installed with
OS provided compilers. Among this software there will be other - usually more recent - compilers
that, once loaded, will prepend new directories to MODULEPATH
unlocking all the software
that was compiled with them. This "unlocking" idea can then be extended arbitrarily to
virtual dependencies, as we'll see in the following section.
Core/Compiler/MPI¶
The most widely used hierarchy is the so called Core/Compiler/MPI
where, on top
of the compilers, different MPI libraries also unlock software linked to them.
There are just a few steps needed to adapt the modules.yaml
file we used previously:
enable the
lmod
file generatorchange the
tcl
tag tolmod
remove
tcl
specific directives (naming_scheme
andconflict
)declare which compilers are considered
core_compilers
remove the
mpi
related suffixes (as they will be substituted by hierarchies)
After these modifications your configuration file should look like:
modules:
enable::
- lmod
lmod:
core_compilers:
- 'gcc@5.4.0'
hierarchy:
- mpi
hash_length: 0
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
suffixes:
'^openblas': openblas
'^netlib-lapack': netlib
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
gcc:
environment:
set:
CC: gcc
CXX: g++
FC: gfortran
F90: gfortran
F77: gfortran
openmpi:
environment:
set:
SLURM_MPI_TYPE: pmi2
OMPI_MCA_btl_openib_warn_default_gid_prefix: '0'
注釈
- Double colon in configuration files
The double colon after
enable
is intentional and it serves the purpose of overriding the default list of enabled generators so that onlylmod
will be active (see Overriding entire sections for more details).
The directive core_compilers
accepts a list of compilers. Everything built
using these compilers will create a module in the Core
part of the hierarchy,
which is the entry point for hierarchical module files. It is
common practice to put the OS provided compilers in the list and only build common utilities
and other compilers with them.
If we now regenerate the module files:
$ spack module lmod refresh --delete-tree -y
==> Regenerating lmod module files
and update MODULEPATH
to point to the Core
:
$ module purge
$ module unuse $HOME/spack/share/spack/modules/linux-ubuntu16.04-x86_64
$ module use $HOME/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/Core
asking for the available modules will return:
$ module avail
----------------------------------------------------------- share/spack/lmod/linux-ubuntu16.04-x86_64/Core ------------------------------------------------------------
gcc/7.2.0
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
Unsurprisingly, the only visible module is gcc
. Loading that we'll unlock
the Compiler
part of the hierarchy:
$ module load gcc
$ module avail
------------------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/gcc/7.2.0 --------------------------------------------
autoconf/2.69 findutils/4.6.0 libtool/2.4.6 netlib-lapack/3.8.0 perl/5.26.2 python/2.7.15 xz/5.2.4
automake/1.16.1 gdbm/1.14.1 libxml2/2.9.8 numactl/2.0.11 pkgconf/1.4.2 readline/7.0 zlib/1.2.11
bzip2/1.0.6 hwloc/1.11.9 m4/1.4.18 openblas/0.3.3 py-numpy/1.15.2-openblas sqlite/3.23.1
cmake/3.12.3 libpciaccess/0.13.5 mpich/3.2.1 openmpi/3.1.3 py-scipy/1.1.0-openblas texinfo/6.5
diffutils/3.6 libsigsegv/2.11 ncurses/6.1 openssl/1.0.2o py-setuptools/40.4.3 util-macros/1.19.1
----------------------------------------------------------- share/spack/lmod/linux-ubuntu16.04-x86_64/Core ------------------------------------------------------------
gcc/7.2.0 (L)
Where:
L: Module is loaded
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
The same holds true also for the MPI
part, that you can enable by loading
either mpich
or openmpi
. Let's start by loading mpich
:
$ module load mpich
$ module avail
--------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/mpich/3.2.1-vt5xcat/gcc/7.2.0 ----------------------------------
netlib-scalapack/2.0.2-netlib netlib-scalapack/2.0.2-openblas (D)
------------------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/gcc/7.2.0 --------------------------------------------
autoconf/2.69 findutils/4.6.0 libtool/2.4.6 netlib-lapack/3.8.0 perl/5.26.2 python/2.7.15 xz/5.2.4
automake/1.16.1 gdbm/1.14.1 libxml2/2.9.8 numactl/2.0.11 pkgconf/1.4.2 readline/7.0 zlib/1.2.11
bzip2/1.0.6 hwloc/1.11.9 m4/1.4.18 openblas/0.3.3 py-numpy/1.15.2-openblas sqlite/3.23.1
cmake/3.12.3 libpciaccess/0.13.5 mpich/3.2.1 (L) openmpi/3.1.3 py-scipy/1.1.0-openblas texinfo/6.5
diffutils/3.6 libsigsegv/2.11 ncurses/6.1 openssl/1.0.2o py-setuptools/40.4.3 util-macros/1.19.1
----------------------------------------------------------- share/spack/lmod/linux-ubuntu16.04-x86_64/Core ------------------------------------------------------------
gcc/7.2.0 (L)
Where:
L: Module is loaded
D: Default Module
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
root@module-file-tutorial:/# module load openblas netlib-scalapack/2.0.2-openblas
root@module-file-tutorial:/# module list
Currently Loaded Modules:
1) gcc/7.2.0 2) mpich/3.2.1 3) openblas/0.3.3 4) netlib-scalapack/2.0.2-openblas
At this point we can showcase the improved consistency that a hierarchical layout provides over a non-hierarchical one:
$ module load openmpi
Lmod is automatically replacing "mpich/3.2.1" with "openmpi/3.1.3".
Due to MODULEPATH changes, the following have been reloaded:
1) netlib-scalapack/2.0.2-openblas
Lmod
took care of swapping the MPI provider for us, and it also substituted the
netlib-scalapack
module to conform to the change in the MPI.
In this way we can't accidentally pull-in two different MPI providers at the
same time or load a module file for a package linked to openmpi
when mpich
is also loaded.
Consistency for compilers and MPI is ensured by the tool.
Add LAPACK to the hierarchy¶
The hierarchy just shown is already a great improvement over non-hierarchical layouts,
but it still has an asymmetry: LAPACK
providers cover the same semantic role
as MPI
providers, but yet they are not part of the hierarchy.
To be more practical, this means that although we have gained an improved consistency in
our environment when it comes to MPI
, we still have the same problems as we had before
for LAPACK
implementations:
root@module-file-tutorial:/# module list
Currently Loaded Modules:
1) gcc/7.2.0 2) openblas/0.3.3 3) openmpi/3.1.3 4) netlib-scalapack/2.0.2-openblas
root@module-file-tutorial:/# module load netlib-scalapack/2.0.2-netlib
The following have been reloaded with a version change:
1) netlib-scalapack/2.0.2-openblas => netlib-scalapack/2.0.2-netlib
root@module-file-tutorial:/# module list
Currently Loaded Modules:
1) gcc/7.2.0 2) openblas/0.3.3 3) openmpi/3.1.3 4) netlib-scalapack/2.0.2-netlib
Hierarchies that are deeper than Core
/Compiler
/MPI
are
probably still considered "unusual" or "impractical" at many sites, mainly because
module files are written manually and keeping track of the combinations
among multiple providers quickly becomes quite involved.
For instance, having both MPI
and LAPACK
in the hierarchy
means we must classify software into one of four categories:
Software that doesn't depend on
MPI
orLAPACK
Software that depends only on
MPI
Software that depends only on
LAPACK
Software that depends on both
to decide when to show it to the user. The situation becomes more involved as the number of virtual dependencies in the hierarchy increases.
We can take advantage of the DAG that Spack maintains for the installed software and solve this combinatorial problem in a clean and automated way. In some sense Spack's ability to manage this combinatorial complexity makes deeper hierarchies feasible.
Coming back to our example, let's add lapack
to the hierarchy and remove any remaining suffix:
modules:
enable::
- lmod
lmod:
core_compilers:
- 'gcc@5.4.0'
hierarchy:
- mpi
- lapack
hash_length: 0
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
gcc:
environment:
set:
CC: gcc
CXX: g++
FC: gfortran
F90: gfortran
F77: gfortran
openmpi:
environment:
set:
SLURM_MPI_TYPE: pmi2
OMPI_MCA_btl_openib_warn_default_gid_prefix: '0'
After module files have been regenerated as usual:
root@module-file-tutorial:/# module purge
root@module-file-tutorial:/# spack module lmod refresh --delete-tree -y
==> Regenerating lmod module files
we can see that now we have additional components in the hierarchy:
$ module load gcc
$ module load openblas
$ module avail
-------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/openblas/0.3.3-xxoxfh4/gcc/7.2.0 --------------------------------
py-numpy/1.15.2 py-scipy/1.1.0
------------------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/gcc/7.2.0 --------------------------------------------
autoconf/2.69 findutils/4.6.0 libtool/2.4.6 netlib-lapack/3.8.0 perl/5.26.2 sqlite/3.23.1
automake/1.16.1 gdbm/1.14.1 libxml2/2.9.8 numactl/2.0.11 pkgconf/1.4.2 texinfo/6.5
bzip2/1.0.6 hwloc/1.11.9 m4/1.4.18 openblas/0.3.3 (L) py-setuptools/40.4.3 util-macros/1.19.1
cmake/3.12.3 libpciaccess/0.13.5 mpich/3.2.1 openmpi/3.1.3 python/2.7.15 xz/5.2.4
diffutils/3.6 libsigsegv/2.11 ncurses/6.1 openssl/1.0.2o readline/7.0 zlib/1.2.11
----------------------------------------------------------- share/spack/lmod/linux-ubuntu16.04-x86_64/Core ------------------------------------------------------------
gcc/7.2.0 (L)
Where:
L: Module is loaded
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
$ module load openmpi
$ module avail
--------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/openmpi/3.1.3-do5xfer/openblas/0.3.3-xxoxfh4/gcc/7.2.0 ---------------------
netlib-scalapack/2.0.2
-------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/openblas/0.3.3-xxoxfh4/gcc/7.2.0 --------------------------------
py-numpy/1.15.2 py-scipy/1.1.0
------------------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/gcc/7.2.0 --------------------------------------------
autoconf/2.69 findutils/4.6.0 libtool/2.4.6 netlib-lapack/3.8.0 perl/5.26.2 sqlite/3.23.1
automake/1.16.1 gdbm/1.14.1 libxml2/2.9.8 numactl/2.0.11 pkgconf/1.4.2 texinfo/6.5
bzip2/1.0.6 hwloc/1.11.9 m4/1.4.18 openblas/0.3.3 (L) py-setuptools/40.4.3 util-macros/1.19.1
cmake/3.12.3 libpciaccess/0.13.5 mpich/3.2.1 openmpi/3.1.3 (L) python/2.7.15 xz/5.2.4
diffutils/3.6 libsigsegv/2.11 ncurses/6.1 openssl/1.0.2o readline/7.0 zlib/1.2.11
---------------------------------------------- /home/spack1/spack/share/spack/lmod/linux-ubuntu16.04-x86_64/Core ----------------------------------------------
gcc/7.2.0 (L)
Where:
L: Module is loaded
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".
Both MPI
and LAPACK
providers will now benefit from the same safety features:
$ module load py-numpy netlib-scalapack
$ module load mpich
Lmod is automatically replacing "openmpi/3.1.3" with "mpich/3.2.1".
Due to MODULEPATH changes, the following have been reloaded:
1) netlib-scalapack/2.0.2
$ module load netlib-lapack
Lmod is automatically replacing "openblas/0.3.3" with "netlib-lapack/3.8.0".
Inactive Modules:
1) py-numpy
Due to MODULEPATH changes, the following have been reloaded:
1) netlib-scalapack/2.0.2
Because we only compiled py-numpy
with openblas
the module
is made inactive when we switch the LAPACK
provider. The user
environment is now consistent by design!
Working with templates¶
As briefly mentioned in the introduction, Spack uses Jinja2 to generate each individual module file. This means that you have all of its flexibility and power when it comes to customizing what gets generated!
Module file templates¶
The templates that Spack uses to generate module files are stored in the
share/spack/templates/module
directory within the Spack prefix, and
they all share the same common structure. Usually, they start with a
header that identifies the type of module being generated. In the case of
hierarchical module files it's:
-- -*- lua -*-
-- Module file created by spack (https://github.com/spack/spack) on {{ timestamp }}
--
-- {{ spec.short_spec }}
--
The statements within double curly brackets {{ ... }}
denote
expressions
that will be evaluated and substituted at module generation time.
The rest of the file is then divided into
blocks
that can be overridden or extended by users, if need be.
Control structures
, delimited by {% ... %}
,
are also permitted in the template language:
{% block environment %}
{% for command_name, cmd in environment_modifications %}
{% if command_name == 'PrependPath' %}
prepend_path("{{ cmd.name }}", "{{ cmd.value }}", "{{ cmd.separator }}")
{% elif command_name == 'AppendPath' %}
append_path("{{ cmd.name }}", "{{ cmd.value }}", "{{ cmd.separator }}")
{% elif command_name == 'RemovePath' %}
remove_path("{{ cmd.name }}", "{{ cmd.value }}", "{{ cmd.separator }}")
{% elif command_name == 'SetEnv' %}
setenv("{{ cmd.name }}", "{{ cmd.value }}")
{% elif command_name == 'UnsetEnv' %}
unsetenv("{{ cmd.name }}")
{% endif %}
{% endfor %}
{% endblock %}
The locations where Spack looks for templates are specified
in config.yaml
:
# Locations where templates should be found
template_dirs:
- $spack/share/spack/templates
and can be extended by users to employ custom templates, as we'll see next.
Extend the default templates¶
Let's assume one of our software is protected by group membership: allowed users belong to the same linux group, and access is granted at group level. Wouldn't it be nice if people that are not yet entitled to use it could receive a helpful message at module load time that tells them who to contact in your organization to be inserted in the group?
To automate the generation of module files with such site-specific behavior
we'll start by extending the list of locations where Spack looks for module
files. Let's create the file ~/.spack/config.yaml
with the content:
config:
template_dirs:
- $HOME/.spack/templates
This tells Spack to also search another location when looking for template files. Next, we need to create our custom template extension in the folder listed above:
{% extends "modules/modulefile.lua" %}
{% block footer %}
-- Access is granted only to specific groups
if not isDir("{{ spec.prefix }}") then
LmodError (
"You don't have the necessary rights to run \"{{ spec.name }}\".\n\n",
"\tPlease write an e-mail to 1234@foo.com if you need further information on how to get access to it.\n"
)
end
{% endblock %}
Let's name this file group-restricted.lua
. The line:
{% extends "modules/modulefile.lua" %}
tells Jinja2 that we are reusing the standard template for hierarchical module files. The section:
{% block footer %}
-- Access is granted only to specific groups
if not isDir("{{ spec.prefix }}") then
LmodError (
"You don't have the necessary rights to run \"{{ spec.name }}\".\n\n",
"\tPlease write an e-mail to 1234@foo.com if you need further information on how to get access to it.\n"
)
end
{% endblock %}
overrides the footer
block.
Finally, we need to add a couple of lines in modules.yaml
to tell Spack which specs
need to use the new custom template. For the sake of illustration let's assume
it's netlib-scalapack
:
modules:
enable::
- lmod
lmod:
core_compilers:
- 'gcc@5.4.0'
hierarchy:
- mpi
- lapack
hash_length: 0
whitelist:
- gcc
blacklist:
- '%gcc@5.4.0'
- readline
all:
filter:
environment_blacklist: ['CPATH', 'LIBRARY_PATH']
environment:
set:
'{name}_ROOT': '{prefix}'
gcc:
environment:
set:
CC: gcc
CXX: g++
FC: gfortran
F90: gfortran
F77: gfortran
openmpi:
environment:
set:
SLURM_MPI_TYPE: pmi2
OMPI_MCA_btl_openib_warn_default_gid_prefix: '0'
netlib-scalapack:
template: 'group-restricted.lua'
If we regenerate the module files one last time:
root@module-file-tutorial:/# spack module lmod refresh -y netlib-scalapack
==> Regenerating lmod module files
we'll find the following at the end of each netlib-scalapack
module file:
-- Access is granted only to specific groups
if not isDir("/usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-7.2.0/netlib-scalapack-2.0.2-d3lertflood3twaor44eam2kcr4l72ag") then
LmodError (
"You don't have the necessary rights to run \"netlib-scalapack\".\n\n",
"\tPlease write an e-mail to 1234@foo.com if you need further information on how to get access to it.\n"
)
end
and every user that doesn't have access to the software will now be redirected to the right e-mail address where to ask for it!