The guide here explains how to use modules especially on SCC. The original Lmod guide can be found at https://lmod.readthedocs.io/en/latest/010_user.html. The User’s tour of the module command covers the basic uses of modules. The other sections can be read at a later date as issues come up.
Module naming scheme on SCC for Lmod
SCC currently adopted categorize modulefiles naming scheme for Lmod. It using the 'moduleclass' easyconfig parameter to categorize modulefiles on each level of the hierarchy. The top category including bio, cae, compiler, data, devel, lang, lib, math, mpi, numlib, phys, system, toolchain, tools and vis.
Following is a sample of module avail
module avail
--------------------------------------------------------------------------------- /usr/local/scc/modulefiles/all ---------------------------------------------------------------------------------
bio/AFNI/20.0.09 bio/VCFtools/0.1.14-foss-2018b-Perl-5.28.0
bio/AFNI/20.0.17-foss-2018b-Python-3.6.6 (D) bio/VCFtools/0.1.15-foss-2018b-Perl-5.28.0
bio/annovar/2016Feb01-foss-2018b-Perl-5.28.0 bio/VCFtools/0.1.16-foss-2018b-Perl-5.28.0 (D)
bio/annovar/2018Apr16-foss-2018b-Perl-5.28.0 bio/xmedcon/0.16.2-GCCcore-7.3.0-nogui
bio/annovar/2019Oct24-foss-2018b-Perl-5.28.0 (D) bio/Xpression/stable
bio/BamTools/2.4.2-foss-2018b compiler/GCC/4.4.7
bio/BamTools/2.5.1-foss-2018b (D) compiler/GCC/4.7.4
bio/Bazam/1.0.1-Java-1.8 compiler/GCC/4.8.3
bio/BCFtools/1.3-foss-2018b compiler/GCC/4.9.3-2.25
bio/BCFtools/1.3.1-foss-2018b compiler/GCC/5.4.0-2.26
bio/BCFtools/1.9-foss-2018b (D) compiler/GCC/6.4.0-2.28
bio/bcl2fastq2/2.20.0-foss-2018b compiler/GCC/7.3.0-2.30 (D)
bio/Beagle/4.0-Java-1.8 compiler/GCC/8.2.0-2.31.1
bio/Beagle/4.1-Java-1.8 compiler/GCC/8.3.0 (L)
bio/Beagle/5.1-Java-1.8 (D) compiler/GCC/8.3.0-2.32
bio/BEDOPS/2.4.35-foss-2018b devel/Maven/3.6.0
bio/BEDTools/2.25.0-foss-2018b devel/Maven/3.6.3 (D)
bio/BEDTools/2.26.0-foss-2018b lang/Anaconda3/2019.10
bio/BEDTools/2.27.1-foss-2018b lang/Java/1.6.0_45 (1.6)
bio/BEDTools/2.28.0-foss-2018b lang/Java/1.7.0_80 (1.7)
bio/BEDTools/2.29.2-foss-2018b (D) lang/Java/1.8.0_112
bio/BioPerl/1.7.2-foss-2018b-Perl-5.28.0 lang/Java/1.8.0_241 (1.8)
bio/BioPerl/1.7.2-GCCcore-8.3.0 (D) lang/Java/11.0.6 (11)
bio/Biopython/1.72-foss-2018b-Python-3.6.6 lang/Java/13.0.2 (D:13)
bio/Biopython/1.75-foss-2019b-Python-3.7.4 (D) lang/Miniconda3/4.7.12.1
bio/BLAST/2.10.0-Linux_x86_64 lang/Perl/5.24.0-GCCcore-5.4.0
bio/BWA/0.7.15-foss-2018b lang/Perl/5.26.0-GCCcore-6.4.0
bio/BWA/0.7.17-foss-2018b (D) lang/Perl/5.28.0-GCCcore-7.3.0
bio/bwakit/0.7.12_x64-linux lang/Perl/5.28.1-GCCcore-8.2.0
bio/bwakit/0.7.15_x64-linux (D) lang/Perl/5.30.0-GCCcore-7.3.0
bio/CCRaVAT/2009 lang/Perl/5.30.0-GCCcore-8.3.0 (D)
bio/Circos/0.69-6-GCCcore-7.3.0-Perl-5.28.0 lang/PSPP/1.0.1-centos7
bio/ConnectomeWorkbench/1.3.2-foss-2018b lang/PSPP/1.0.1-nogui-centos7
bio/ConnectomeWorkbench/1.3.2 lang/PSPP/1.2.0-centos7
bio/ConnectomeWorkbench/1.4.2-foss-2018b (D) lang/PSPP/1.2.0-nogui-centos7 (D)
bio/Cufflinks/2.2.1-foss-2018b lang/Python/2.7.17-anaconda-2020a (2.7)
bio/cutadapt/1.18-foss-2018b-Python-3.6.6 lang/Python/3.6.10-anaconda-2020a (3.6)
bio/cutadapt/2.1-foss-2018b-Python-3.6.6 (D) lang/Python/3.7.6-anaconda-2020a (D:3.7)
bio/Cytoscape/3.6.1 lang/R/3.5.3-foss-2018b-bare
bio/Cytoscape/3.7.2 (D) lang/R/3.5.3-foss-2018b-scc-2020a
bio/DeepSEA/0.94 lang/R/3.6.2-foss-2018b-bare
bio/dicomtools/0.8.6-linux64 lang/R/3.6.2-foss-2018b-scc-2020a (D)
User’s Tour of the Module Command
The module command sets the appropriate environment variable independent of the user’s shell. Typically the system will load a default set of modules. A user can list the modules loaded by:
[user@dev01 ~]# module load
To find out what modules are available to be loaded a user can do:
$ module avail
To load packages a user simply does:
$ module load package1 package2 ...
To unload packages a user does:
$ module unload package1 package2 ...
A user might wish to change from one compiler to another:
$ module load compiler/GCC/7.3.0-2.30
module swap compiler/GCC/7.3.0-2.30 compiler/GCC/8.3.0-2.32
The above command is short for:
$ module unload compiler/GCC/7.3.0-2.30
$ module load compiler/GCC/8.3.0-2.32
A user may wish to go back to an initial set of modules:
$ module reset
This will unload all currently loaded modules, including the sticky ones, then load the list of modules specified by LMOD_SYSTEM_DEFAULT_MODULES. There is a related command:
$ module restore
This command will also unload all currently loaded modules, including the sticky ones, and then load the system default unless the user has a default collection. See User Collections for more details.
If a module is not available then an error message is produced:
$ module load packageXYZ
Lmod has detected the following error: The following module(s) are unknown: "packageXYZ"
Please check the spelling or version number. Also try "module spider ..."
It is also possible your cache file is out-of-date; it may help to try:
help to try:
$ module --ignore-cache load "packageXYZ"
Also make sure that all modulefiles written in TCL start with the string #%Module
If you don't understand the warning or error, contact the SCC support at <SCC.Support@camh.ca>
It is possible to try to load a module with no error message if it does not exist:
$ module try-load packageXYZ
Modulefiles can contain help messages. To access a modulefile’s help do:
$ module help bio/SAMtools/1.10-foss-2018b
To get a list of all the commands that module knows about do:
$ module help
The module avail command has search capabilities:
$ module avail cc
will list for any modulefile where the name contains the string “cc”.
$ module avail bio/
will list for any modulefile where the name begins with the string “bio/”, namely in bio category.
Users may wish to test whether certain modules are already loaded:
$ module is-loaded packageName1 packageName2 ...
Lmod will return a true status if all modules are loaded and a false status if one is not. Note that Lmod is setting the status bit, there is nothing printed out. This means that one can do the following:
$ if module is-loaded pkg ; then "echo pkg is loaded"; fi
Users also may wish to test whether certain modules can be loaded with the current $MODULEPATH:
$ module is-avail packageName1 packageName2 ...
Lmod will a true status if all modules are available and false if one can not be loaded. Again this command sets the status bit.
Modulefiles can have a description section known as “whatis”. It is accessed by:
$ module whatis bio/SAMtools/1.10-foss-2018b
-------------------------------------------------------------------- Module Specific Help for "bio/SAMtools/1.10-foss-2018b" ---------------------------------------------------------------------
Description
===========
SAM Tools provide various utilities for manipulating alignments in the SAM format, including sorting, merging, indexing and generating alignments in a per-position format.
More information
================
- Homepage: http://www.htslib.org
Finally, there is a keyword search tool:
$ module keyword word1 word2 ...
This will search any help message or whatis description for the word(s) given on the command line.
Another way to search for modules is with the “module spider” command. This command searches the entire list of possible modules. The difference between “module avail” and “module spider” is explained in the “Module Hierarchy” and “Searching for Modules” section.:
$ module spider
Specifying modules to load
Modules are a way to ask for a certain version of a package. For example SCC have two or more versions of the gcc compiler collection (say versions 7.3 and 8.3). So a user may load:
$ module load compiler/GCC
or:
$ module load compiler/GCC/8.3.0
In the second case, Lmod will load gcc version 8.3.0 where as in the first case Lmod will load the default version of gcc which SCC marks 7.3.0-2.30 as the default.
In this user guide, we call compiler/GCC/7.3.0-2.30 the fullName of the module and compiler/gcc as the shortName. We also call what the user asked for as the userName which could either be the fullName or the shortName depending on what the user typed on the command line.
ml: A convenient tool
For those of you who can’t type the mdoule, moduel, err module command correctly, Lmod has a tool for you. With ml you won’t have to type the module command again. The two most common commands are module list and module load <something> and ml does both:
$ ml
means module list. And:
$ ml foo
means module load foo while:
$ ml -bar
means module unload bar. It won’t come as a surprise that you can combine them:
$ ml foo -bar
means module unload bar; module load foo. You can do all the module commands:
$ ml spider
$ ml avail
$ ml show foo
If you ever have to load a module name spider you can do:
$ ml load spider
If you are ever forced to type the module command instead of ml then that is a bug and should be reported.
clearLmod: Complete remove Lmod setup
It is rare, but sometimes a user might need to remove the Lmod setup from their current shell. This command can be used with bash/zsh/csh/tcsh to remove the Lmod setup:
$ clearLmod
This command prints a message telling the user what it has done. This message can be silented with:
$ clearLmod --quiet
SAFETY FEATURES
(1): Users can only have one version active: The One Name Rule
If a user does:
$ module avail xyz
-------------- /opt/apps/modulefiles ----------------
xyz/8.1 xyz/11.1 (D) xyz/12.1
$ module load xyz
$ module load xyz/12.0
The first load command will load the 11.1 version of xyz. In the second load, the module command knows that the user already has xyz/11.1 loaded so it unloads that and then loads xyz/12.0. This protection is only available with Lmod.
This is known as the One Name rule. This feature is core to how Lmod works and there is no way to override this.
(2) : Users can only load one compiler or MPI stack at a time.
Lmod provides an additional level of protection. If each of the compiler modulefiles add a line:
family("compiler")
Then Lmod will not load another compiler modulefile. Another benefit of the modulefile family directive is that an environment variable “LMOD_FAMILY_COMPILER” is assigned the name (and not the version). This can be useful specifying different options for different compilers. In the High Performance Computing (HPC) world, the message passing interface (MPI) libraries are important. The mpi modulefiles can contain a family(“MPI”) directive which will prevent users from loading more than one MPI implementation at a time. Also the environment variable “LMOD_FAMILY_MPI” is defined to the name of the mpi library.
Controlling Modules During Login
Normally when a user logs in, there are a standard set of modules that are automatically loaded. Users can override and add to this standard set in two ways. The first is adding module commands to their personal startup files. The second way is through the “module save” command.
To add module commands to users’ startup scripts requires a few steps. Bash users can put the module commands in either their ~/.profile file or their ~/.bashrc file. It is simplest to place the following in their ~/.profile file:
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
and place the following in their ~/.bashrc file:
if [ -z "$BASHRC_READ" ]; then
export BASHRC_READ=1
# Place any module commands here
# module load git
fi
By wrapping the module command in an if test, the module commands need only be read in once. Any sub-shell will inherit the PATH and other environment variables automatically. On login shells the ~/.profile file is read which, in the above setup, causes the ~/.bashrc file to be read. On interactive non-login shells, the ~/.bashrc file is read instead. Obviously, having this setup means that module commands need only be added in one file and not two.
Csh users need only specify the module commands in their ~/.cshrc file as that file is always sourced:
if ( ! $?CSHRC_READ ) then
setenv CSHRC_READ 1
# Place any module command here
# module load git
endif
User Collections
User defined initial list of login modules:
Assuming that the system administrators have installed Lmod correctly, there is a second way which is much easier to setup. A user logs in with the standard modules loaded. Then the user modifies the default setup through the standard module commands:
$ module unload XYZ
$ module swap gcc ucc
$ module load git
Once users have the desired modules load then they issue:
$ module save
This creates a file called ~/.lmod.d/default which has the list of desired modules. Once this is set-up a user can issue:
$ module restore
and only the desired modules will be loaded. If Lmod is setup correctly (see Providing A Standard Set Of Modules for all Users) then the default collection will be the user’s initial set of modules.
If a user doesn’t have a default collection, the Lmod purges ALL currently loaded modules, including the sticky ones, and loads the list of module specified by LMOD_SYSTEM_DEFAULT_MODULES just like the module reset command.
Users can have as many collections as they like. They can save to a named collection with:
$ module save <collection_name>
and restore that named collection with:
$ module restore <collection_name>
A user can print the contents of a collection with:
$ module describe <collection_name>
A user can list the collections they have with:
$ module savelist
Finally a user can disable a collection with:
$ module disable <collection_name>
If no collection_name is given then the default is disabled. Note that the collection is not remove just renamed. If a user disables the foo collection, the file foo is renamed to foo~. To restore the foo collection, a user will have to do the following:
$ cd ~/.lmod.d; mv foo~ foo
Rules for loading modules from a collection
Lmod has rules on what modules to load when restoring a collection. Remember that userName is what the user asked for, the fullName is the exact module name and shortName is name of the package (e.g. gcc, fftw3).
- Lmod records the fullName and the userName in the collection.
- If the userName is the same as the fullName then it loads fullName independent of the default.
- if the userName is not the same as the fullName then it loads the default.
- Unless LMOD_PIN_VERSIONS=yes then the fullName is always loaded.
In other words if a user does:
$ module --force purge; module load A B C
$ module save
then “module restore” will load the default A, B, and C. So if the default for module A changed between when the collection was saved and then restored, a new version of A will be loaded. This assumes that LMOD_PIN_VERSIONS is not set. If it is set or Lmod is configured that way then if A/1.1, B/2.4 and C/3.3 are the default then those modules will be loaded in the future independent of what the defaults are in the future.
On the other hand:
$ module --force purge; module load A/1.0 B/2.3 C/3.4
$ module save
then “module restore” will load the A/1.0, B/2.3, and C/3.4 independent of what the defaults are now or in the future.
Hidden Modules
SCC have hidden many library and develop modules by default for general users. If you want to search or load some hidden library, you can try the following method:
1.Using –show-hidden parameter
module --show-hidden avail
or
module --show-hidden spider
2.Using unset SCC_LMOD_HIDE env
unset SCC_LMOD_HIDE
module avail
module spider
Disable Lmod for your SCC account
Lmod is compatible with SCC old Environment Modules System. User’s old scripts can run without any modification under Lmod. If you have problem to using the new Lmod, you can still switch back to old module system by the following command:
$ touch ~/.lmod-no
Then log out and log in again make it take effect.