Lmod is a powerful piece of software that ARCC leverages for managing dynamic user environments and access to complicated software stacks. Our configuration of Lmod uses a hierarchy for the organization of software that starts with compilers. Compilers are central to nearly all software installed on Teton. The supported compilers are Intel, GCC, and PGI. There are however some packages that are compiler-independent.
Module spiderThe spider subcommand is a great search tool to find out if the software package has been installed as a system package. From the command line, run the module spider command to output a list of the available software for the entire system:
To search for specific packages and/or versions, you can supply the names/arguments to the command:
If there is only one version, the output will contain information regarding which compilers are required to be loaded before the package can be loaded as well as provide a brief segment on the help of the module. If there are multiple versions available, the output contains which versions are available and instructions to get more information on the individual version. To get information regarding a specific version of the package, include the version as part of the argument:
There are opportunities to use regular expressions to search for modules. See output from module help for more information. ExampleThe general process for all apps you might want to load is:
Type or paste something here to turn it into an excerpt. |
Additionally, using the avail subcommand will show a table of available modules that are capable of being loaded into the current environment.
$ module avail |
Searching by keyword is also an option:
$ module keyword slurm |
The help subcommand will display information regarding the help section of the module and if there is any additional information relating to the installation of the software that is pertinent.
$ module help slurm |
Loading modules and unloading modules are how Lmod dynamically changes the environment on the cluster. To access software available through modules, the specific module must be loaded. There are several modules that are loaded automatically on the system as defaults. They include arcc, slurm, and singularity.
New modules can be loaded with the load subcommand. I.e., to load the Intel compilers with the most up to date version:
$ module load intel |
To remove the software from the environment, using the unload subcommand will remove the module from the environment. If the module specified isn't loaded, this becomes a no-op (no operation).
$ module unload intel |
It is important to note that when loading modules that are dependent on a compiler and the compiler module is unloaded, Lmod will deactivate the dependent modules until the correct compiler is loaded or that an appropriate compiler is loaded that has alternative versions of the software available.
Module collections are a great method to keep certain software stacks in order and switch between them regularly and quickly. They allow for all modules to be loaded, then saved, and recalled later for use.
To save a module collection:
$ module save |
By default, this is will save the loaded modules as the default collection. You can optionally supply a name to the command to give a custom name and have many collections available:
$ module save NAME |
Swapping between collections requires the restore subcommand is used. Without any additional arguments, the module system will load your default collection. If there is no default collection defined, the system default collection will be loaded. Use a NAME as an argument to load a specific collection.
$ module restore $ module restore NAME |
A special condition to load the system defined collection is done with the reset subcommand allowing a fresh start of configured modules. Note, this doesn't take into account what is inserted into shell startup files (i.e., .bashrc, .cshrc, etc.)
$ module reset |
or optionally:
$ module restore system |
To query the system and determine which module collections have been created, use the savelist subcommand.
$ module savelist |
It's important to use names that are memorable, but that doesn't necessarily describe all the contents of the collection. To list which modules are part of the collection, use the describe subcommand with an optional argument to list contents of a certain NAME collection.
$ module describe $ module describe NAME |
To disable a module collection that is no longer needed, use the disable subcommand.
$ module disable NAME |
Some core modules are automatically loaded when logging in. On Teton, these automatically-loaded modules do not include a compiler module such as gcc
or intel
that start the hierarchy for the organization of other modules, since for different users, different choices of default compiler would make sense. However, a user can customize the automatically-loaded modules by adding module load
commands to the .bashrc
file in their home directory.
To automatically load one of the compilers when logging in, append the following lines to your .bashrc
file:
gcc
module load swset/2018.05 module load gcc/7.3.0 |
intel
module load swset/2018.05 module load intel/18.0.1 |
To see if different versions of the compilers are available, and which swset
version a particular compiler version depends on, use the module avail
and module spider
commands described above on this page.
Lmod provides a shorthand interface to the modules command as ml. The command is quite powerful and allows quick access to the modules system. The default action of ml is to list the loaded modules. Providing a module as an argument will load the module.
$ ml intel |
Modules can quickly be unloaded as well by supplying a nearly identical command, but with the - operator before the argument:
$ ml -intel |
Querying the system of available modules is easy:
$ ml av $ ml spider |
The ml command is very useful and should be explored.
All software requested on ARCC HPC clusters generally comes with a module file as the primary method of access. If the software is deemed either too restrictive or is better suited to be offered from the Operating System's package manager, it will be noted in the software request.
Installing Software Yourself on an HPC Cluster
Using Miniconda to Install Software