Modules and Applications¶
Most software available on Cheaha is installed as modules, managed by the Lmod system. This document will provide a basic rundown of using Lmod commands to customize a software environment. module
is the main command used to interface with module files in Lmod.
Listing and Searching Modules¶
To begin, all module commands are run from the terminal. To know what software is installed on Cheaha, use the avail
command.
If you need to know what software is already loaded in your environment, run:
If there is specific software you want to search for, you can use the spider
subcommand, and provide a string or regular expression to match against. All modules containing the string (case-insensitive) or matching the regular expression will be returned along with their installed versions.
# list modules containing string
module spider <string>
# list modules matching a regular expression
module -r spider <regex>
Loading Modules¶
To load modules, run:
Note
If you only specify a module name without an accompanying version tag, the most recently installed version will be loaded into the workspace. If your scripts depend on specific versions of software being used, explicitly load the module version you need.
To unload packages, run:
If you want to revert to the default modules, you can use:
Best Practice for Loading Modules¶
To reduce unexpected behavior and/or to get rid of Lmod errors,
-
Avoid using
module load
in$HOME/.bashrc
. Instead, create a bash script with the module load commands and source it each time to load the modules needed in a shell/sbatch script. Here is an example of loading module in a bash script namedmodule_test.sh
and compilation,#!/bin/bash module reset module load Bowtie/1.1.2-foss-2016a module load SAMtools/1.3.1-foss-2016a module load TopHat/2.1.1-foss-2016a module -t list
$ chmod +x module_test.sh $ source ./module_test.sh Resetting modules to system default # Currently Loaded Modules shared slurm/18.08.9 rc-base DefaultModules GCCcore/4.9.3 binutils/2.25-GCCcore-4.9.3 GCC/4.9.3-2.25 numactl/2.0.11-GCC-4.9.3-2.25 hwloc/1.11.2-GCC-4.9.3-2.25 OpenMPI/1.10.2-GCC-4.9.3-2.25 OpenBLAS/0.2.15-GCC-4.9.3-2.25-LAPACK-3.6.0 gompi/2016a FFTW/3.3.4-gompi-2016a ScaLAPACK/2.0.2-gompi-2016a-OpenBLAS-0.2.15-LAPACK-3.6.0 foss/2016a Bowtie/1.1.2-foss-2016a ncurses/6.0-foss-2016a zlib/1.2.8-foss-2016a SAMtools/1.3.1-foss-2016a bzip2/1.0.6-foss-2016a Boost/1.61.0-foss-2016a TopHat/2.1.1-foss-2016a
-
Before loading modules in a shell/bash/sbatch script, use a clean shell by using
module reset
at the beginning to restore to default system settings. Usingmodule reset
before loading modules separates what software is loaded in the working shell from the software loaded in the script shell. Be aware that forked processes (like scripts) and Slurm commands inherit the environment variables of the working shell, including loaded modules. Here is an example that shows module conflict between cuda11.8 and cuda11.4 versions that may lead to unexpected behavior or an erroneous output.
# Working shell where you may try testing module load and your run script
$ module load cuda11.4/toolkit
$ module -t list
#Currently Loaded Modules
shared
slurm/18.08.9
rc-base
DefaultModules
cuda11.4/toolkit/11.4.2
# bash script you are passing in a sbatch script
#!/bin/bash
module load cuda11.8/toolkit
module -t list
# Not using `module reset` at the beginning of the bash script could cause CUDA conflict issues.
$ source ./module_test2.sh
#Currently Loaded Modules
shared
slurm/18.08.9
rc-base
DefaultModules
cuda11.4/toolkit/11.4.2
cuda11.8/toolkit/11.8.0
Note
The best practice would be to avoid using module reset
in the Environment Setup
of Open OnDemand jobs as the OOD session, by default, resets the module at the beginning of every session. It is observed to cause unexpected behavior if module reset
is used in the Rstudio server OOD sessions.
Licensed and Commercial Software Restrictions¶
The following software have license restrictions that may preclude some researchers or collaborators depending on their departmental or group affiliations. In the table, "affiliated" means employed by, or a student of, unless otherwise noted. External collaborators are not considered affiliated with UAB for the purposes of software licensing and access, unless otherwise noted. These software packages may be commercial paid software. If you believe you should have access to software that you do not have access to, please contact Support.
Software | Restrictions | License Holder |
---|---|---|
Ansys | School of Engineering affiliated | School of Engineering |
Gurobi | One individual user per license | Individuals |
LS-Dyna | School of Engineering affiliated | School of Engineering |
MATLAB | UAB affiliated | UAB Campus |
Parabricks | 2 GPUs for researchers using RC systems | Research Computing |
SAS | UAB affiliated | UAB Campus |
Stata | UAB affiliated | UAB Campus |
Use of these software packages without authorization may be a violation of the UAB IT Acceptable Use Policy.
Security Issues¶
IGV¶
Danger
Versions of IGV prior to 2.11.9
use a compromised version of log4j. Those versions are affected by a serious remote code execution issue. Please transition your software to use versions of IGV >= 2.11.9
.
GSEA¶
Danger
Versions of GSEA prior to 4.2.3
use a compromised version of log4j. Those versions are affected by a serious remote code execution issue. Please transition your software to use versions of GSEA >= 4.2.3
.