The Module System: LMOD

Overview

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.

Searching for Modules

Module spider

The 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:

$ module spider

To search for specific packages and/or versions, you can supply the names/arguments to the command:

$ module spider samtools

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:

$ module spider samtools/1.6

There are opportunities to use regular expressions to search for modules. See output from module help for more information.

Example

The general process for all apps you might want to load is:

  1. Find versions.

  2. Find a version’s dependencies.

  3. Check what is already loaded and what is missing.

  4. Load required (missing) dependencies.

  5. Load application.

 

Module avail

Additionally, using the avail subcommand will show a table of available modules that are capable of being loaded into the current environment.

Keyword search

Searching by keyword is also an option:

Information About A Module

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.

Loading / Unloading Modules

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 arccslurm, 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:

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).

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

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:

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:

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.

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.)

or optionally:

To query the system and determine which module collections have been created, use the savelist subcommand.

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.

To disable a module collection that is no longer needed, use the disable subcommand.

Automatically Loading Modules

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.

Examples

To automatically load one of the compilers when logging in, append the following lines to your .bashrc file:

For gcc
For intel

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.

Module shorthand with ml

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.

Modules can quickly be unloaded as well by supplying a nearly identical command, but with the - operator before the argument:

Querying the system of available modules is easy:

The ml command is very useful and should be explored.

Requesting Software with Module

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

Creating Private Modules (Advanced)

Using Miniconda to Install Software