Lmod
Chinook already has builds of many third-party software packages that are used by multiple projects on Chinook. There are often multiple builds of a particular software package - different versions, different compilers used to build the software, different compile-time flags, et cetera. To avoid conflicts between these many disparate package builds, Chinook employs the Lmod environment module system which you can use to load and unload different combinations of software packages into your environment.
Common commands and loading modules
module list - will show the current modules you have loaded
module load moduleName/version - will load a module named moduleName, at a specific version
module unload moduleName/version - will unload a module
module avail (or module av) - show all available modules to load, based on the modules you have loaded
module spider moduleName - search for a specific moduleName. The output will list what needs to be loaded to be able to load the module you searched for
module keyword - search all modules for a specific keyword
Loading modules will only be active for the current session you are in. Each time you log into Chinook you will need to reload any modules. If you wish to avoid this you can add any module commands to your .bashrc.
You should also make sure to load any modules in batch scripts you submit to Slurm.
What are Environment Modules?
We use the Lmod enviornment module system on Chinook for its expanded capabilities over the Tcl environment module system.
The environment modules found on Chinook (often referred to simply as "modules") are Lua script files that are used to update shell environment variables such as PATH, MANPATH, and LD_LIBRARY_PATH. These variables allow your shell to discover the particular application or library as specified by the module. Some environment modules set additional variables (such as PYTHONPATH or PERL5LIB), while others simply load a suite of other modules.
Toolchains
Software on chinook is built using Toolchains, which are a selection of compilers and various software, such as MPI or BLAS, that are commonly needed for software packages. Toolchains allow us to simplify our software builds and guarantees that modules that were built with the same toolchain will work together when both are loaded.
We use two toolchains to build our software and generally try to build all software using both. These toolchains are the foss (Free Open Source Software) and intel.
Hierarchical Naming Scheme
Note: If you just wish to see the maximum amount of modules for our two main toolchains (intel and foss/GNU) you should run the following commands:
or
Our current module setup uses a Hierarchical Naming Scheme for loading modules. Modules are presented in a hierarchy of different levels, starting from a top "core" level (typically compilers and other system software) then going to a "compiler" level (for software build with a specific compiler toolchain), followed by an "MPI" level (software build with a specific compiler + MPI toolchain).
Each level will act as a "gateway" to the next level down, meaning you must load a compiler module at the "core" level to see modules at the "compiler" level with the "module avail" command.
If you wish to see the maximum amount of modules available for the GCC suite of compilers you can run:
module load foss/2022a
or for the Intel suite of compilers:
module load intel/2023a
and "module avail" will show all available modules build using the GCC or Intel compilers.
With no modules loaded:
After loading the foss toolchain:
Last updated