Modules: Difference between revisions
No edit summary |
No edit summary |
||
(38 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
=GNU Modules= | =GNU Modules= | ||
Many large institutions use the concept of Modules to load software into user environments. They provide a way to add and remove environmental variables that provide access to UMIACS' large set of software that we offer on our [[RHEL | Red Hat Enterprise Linux (RHEL)]] and [[Ubuntu]] platforms. They work by customizing your shell environment which is done automatically for the two major shell families (bash/sh (default shell) and tcsh/csh). If you use an alternate shell, please look to source the appropriate script for your shell in <tt>/usr/share/Modules/init</tt>. | |||
Initially your module environment is empty, though included in your module path are local operating system specific modules, locally built software modules, and binary software modules (Matlab, Intel Compiler, etc.). | |||
Initially your module environment is empty though included in your | |||
==Available Software== | ==Available Software== | ||
To see if a piece of software is available | To see if a piece of software is available, use the <tt>module avail</tt> command. This can be given a trailing prefix on the command line to search a subset of the available software. | ||
<pre> | <pre> | ||
[ | [username@nexusstaff00 ~]$ module avail cuda | ||
--------------------------- /opt/common/.modulefiles --------------------------- | |||
cuda/3.2.16 cuda/6.5.14 cuda/9.0.176 cuda/11.0.3 cuda/11.8.0 | |||
cuda/4.2.9 cuda/7.0.28 cuda/9.1.85 cuda/11.1.1 cuda/12.0.1 | |||
cuda/5.0.35 cuda/7.5.18 cuda/9.2.148 cuda/11.2.2 cuda/12.1.1 | |||
cuda/5.5.11 cuda/8.0.27rc2 cuda/10.0.130 cuda/11.3.1 | |||
cuda/5.5.22 cuda/8.0.44 cuda/10.1.243 cuda/11.4.4 | |||
cuda/6.0.37 cuda/8.0.61 cuda/10.2.89 cuda/11.7.0 | |||
</pre> | </pre> | ||
<pre> | <pre> | ||
[ | [username@nexusstaff00 ~]$ module avail Python3 | ||
------------------------- /opt/local/stow/.modulefiles ------------------------- | |||
Python3/3.5.2 Python3/3.8.2 Python3/3.8.15 Python3/3.9.16 | |||
Python3/3.6.15 Python3/3.8.10 Python3/3.9.5 Python3/3.10.4 | |||
Python3/3.7.13 Python3/3.8.12 Python3/3.9.6 Python3/3.10.10 | |||
Python3/3.7.16 Python3/3.8.13 Python3/3.9.12 Python3/3.11.2 | |||
</pre> | </pre> | ||
Some pieces of software may have default versions that are loaded if no version is explicitly specified, indicated by <code>(default)</code> coming after their name/version in the output of <tt>module avail</tt>. If a piece of software does not have any default version and you load it without specifying a version, you will load the most recent version of it. | |||
==Adding Modules into your Environment== | ==Adding Modules into your Environment== | ||
Line 29: | Line 33: | ||
<pre> | <pre> | ||
[ | [username@nexusstaff00 ~]$ module add cuda | ||
</pre> | </pre> | ||
Line 35: | Line 39: | ||
<pre> | <pre> | ||
[ | [username@nexusstaff00 ~]$ module add Python3/3.10.10 | ||
</pre> | |||
==Listing Modules== | |||
You can list the currently loaded modules in your environment by using the '''list''' command. | |||
<pre> | |||
[username@nexusstaff00 ~]$ module list | |||
Currently Loaded Modulefiles: | |||
1) Python3/3.10.10 2) cuda/12.1.1 | |||
</pre> | |||
==Showing a Module== | |||
You can show what the module is going to add to your environment (and the dependencies that will be added) with the '''show''' command. | |||
<pre> | |||
[username@nexusstaff00 ~]$ module show cuda | |||
------------------------------------------------------------------- | |||
/opt/common/.modulefiles/cuda/12.1.1: | |||
conflict cuda/12.0.1 cuda/11.8.0 cuda/11.7.0 cuda/11.4.4 cuda/11.2.2 cuda/11.1.1 cuda/11.0.3 cuda/10.2.89 cuda/10.1.243 cuda/10.0.130 cuda/9.2.148 cuda/9.1.85 cuda/9.0.176 cuda/8.0.61 cuda/8.0.44 cuda/8.0.27rc2 cuda/7.5.18 cuda/7.0.28 cuda/6.5.14 cuda/6.0.37 cuda/5.5.22 cuda/5.5.11 cuda/5.0.35 cuda/4.2.9 cuda/3.2.16 | |||
prepend-path PATH /opt/common/cuda/cuda-12.1.1/bin | |||
prepend-path LD_LIBRARY_PATH /opt/common/cuda/cuda-12.1.1/lib64 | |||
prepend-path LD_RUN_PATH /usr/lib64/nvidia:/usr/lib/nvidia:/opt/common/cuda/cuda-12.1.1/lib64:/opt/common/cuda/cuda-12.1.1/lib | |||
prepend-path LIBRARY_PATH /usr/lib64/nvidia:/usr/lib/nvidia:/opt/common/cuda/cuda-12.1.1/lib64:/opt/common/cuda/cuda-12.1.1/lib | |||
prepend-path CPATH /opt/common/cuda/cuda-12.1.1/include | |||
prepend-path PKG_CONFIG_PATH /opt/common/cuda/cuda-12.1.1/pkgconfig | |||
setenv CUDA_HOME /opt/common/cuda/cuda-12.1.1 | |||
------------------------------------------------------------------- | |||
</pre> | </pre> | ||
==Removing Modules in your Environment== | ==Removing Modules in your Environment== | ||
If you want to remove a module because it conflicts or you want to clean up your environment you can by using the <tt>module rm <module></tt> command. | If you want to remove a module because it conflicts or you want to clean up your environment you can by using the <tt>module rm <module></tt> command. | ||
==Using Modules in Scripts== | ==Using Modules in Scripts== | ||
Line 51: | Line 82: | ||
</pre> | </pre> | ||
=== | ===Tcsh=== | ||
<pre> | <pre> | ||
source /usr/share/Modules/init/tcsh | source /usr/share/Modules/init/tcsh | ||
Line 57: | Line 88: | ||
</pre> | </pre> | ||
==Modules in Non-Interactive Shell Sessions== | |||
In non-interactive shell sessions (non-login shells), the Modules configuration environment will not automatically load. This will also occur if the OS version of the compute node you are scheduled on is different from the OS version of the submission node you are submitting the job from. | |||
If you will need the use of Modules in non-interactive [[SLURM]] jobs, cross-OS jobs, or other similar sessions, you will need to include the following in your shell init scripts. For [[SLURM]] specifically, please ensure you include these statements after any #SBATCH directives in your submission batch scripts, otherwise these directives will not work. | |||
===Bash=== | ===Bash=== | ||
Line 66: | Line 99: | ||
</pre> | </pre> | ||
=== | ===Tcsh=== | ||
<pre> | <pre> | ||
source /usr/share/Modules/init/tcsh | source /usr/share/Modules/init/tcsh | ||
source /etc/profile.d/ummodules.csh | source /etc/profile.d/ummodules.csh | ||
</pre> | </pre> | ||
==Modules on RHEL9 Desktop Sessions== | |||
Because of changes made in GNOME between RHEL8 and RHEL9, the <tt>module</tt> command will not work on desktop sessions out of the box. In order to use modules in a shell opened from a desktop session, you must source the modules init script. See [[#Modules in Non-Interactive Shell Sessions]] for the required commands. For convenience, we recommend adding this to the top of your shell init file (e.g ~/.bashrc, ~/.tcshrc), this way it gets sourced automatically with each new shell. | |||
Note that this issue does not affect RHEL9 SSH sessions, only sessions using the desktop GUI. | |||
==Additional Help== | ==Additional Help== |
Latest revision as of 15:56, 20 November 2024
GNU Modules
Many large institutions use the concept of Modules to load software into user environments. They provide a way to add and remove environmental variables that provide access to UMIACS' large set of software that we offer on our Red Hat Enterprise Linux (RHEL) and Ubuntu platforms. They work by customizing your shell environment which is done automatically for the two major shell families (bash/sh (default shell) and tcsh/csh). If you use an alternate shell, please look to source the appropriate script for your shell in /usr/share/Modules/init.
Initially your module environment is empty, though included in your module path are local operating system specific modules, locally built software modules, and binary software modules (Matlab, Intel Compiler, etc.).
Available Software
To see if a piece of software is available, use the module avail command. This can be given a trailing prefix on the command line to search a subset of the available software.
[username@nexusstaff00 ~]$ module avail cuda --------------------------- /opt/common/.modulefiles --------------------------- cuda/3.2.16 cuda/6.5.14 cuda/9.0.176 cuda/11.0.3 cuda/11.8.0 cuda/4.2.9 cuda/7.0.28 cuda/9.1.85 cuda/11.1.1 cuda/12.0.1 cuda/5.0.35 cuda/7.5.18 cuda/9.2.148 cuda/11.2.2 cuda/12.1.1 cuda/5.5.11 cuda/8.0.27rc2 cuda/10.0.130 cuda/11.3.1 cuda/5.5.22 cuda/8.0.44 cuda/10.1.243 cuda/11.4.4 cuda/6.0.37 cuda/8.0.61 cuda/10.2.89 cuda/11.7.0
[username@nexusstaff00 ~]$ module avail Python3 ------------------------- /opt/local/stow/.modulefiles ------------------------- Python3/3.5.2 Python3/3.8.2 Python3/3.8.15 Python3/3.9.16 Python3/3.6.15 Python3/3.8.10 Python3/3.9.5 Python3/3.10.4 Python3/3.7.13 Python3/3.8.12 Python3/3.9.6 Python3/3.10.10 Python3/3.7.16 Python3/3.8.13 Python3/3.9.12 Python3/3.11.2
Some pieces of software may have default versions that are loaded if no version is explicitly specified, indicated by (default)
coming after their name/version in the output of module avail. If a piece of software does not have any default version and you load it without specifying a version, you will load the most recent version of it.
Adding Modules into your Environment
You can simply add a module into your environment by using the module add <module> command.
[username@nexusstaff00 ~]$ module add cuda
You can also specify a specific version of the software when we have multiple ones available.
[username@nexusstaff00 ~]$ module add Python3/3.10.10
Listing Modules
You can list the currently loaded modules in your environment by using the list command.
[username@nexusstaff00 ~]$ module list Currently Loaded Modulefiles: 1) Python3/3.10.10 2) cuda/12.1.1
Showing a Module
You can show what the module is going to add to your environment (and the dependencies that will be added) with the show command.
[username@nexusstaff00 ~]$ module show cuda ------------------------------------------------------------------- /opt/common/.modulefiles/cuda/12.1.1: conflict cuda/12.0.1 cuda/11.8.0 cuda/11.7.0 cuda/11.4.4 cuda/11.2.2 cuda/11.1.1 cuda/11.0.3 cuda/10.2.89 cuda/10.1.243 cuda/10.0.130 cuda/9.2.148 cuda/9.1.85 cuda/9.0.176 cuda/8.0.61 cuda/8.0.44 cuda/8.0.27rc2 cuda/7.5.18 cuda/7.0.28 cuda/6.5.14 cuda/6.0.37 cuda/5.5.22 cuda/5.5.11 cuda/5.0.35 cuda/4.2.9 cuda/3.2.16 prepend-path PATH /opt/common/cuda/cuda-12.1.1/bin prepend-path LD_LIBRARY_PATH /opt/common/cuda/cuda-12.1.1/lib64 prepend-path LD_RUN_PATH /usr/lib64/nvidia:/usr/lib/nvidia:/opt/common/cuda/cuda-12.1.1/lib64:/opt/common/cuda/cuda-12.1.1/lib prepend-path LIBRARY_PATH /usr/lib64/nvidia:/usr/lib/nvidia:/opt/common/cuda/cuda-12.1.1/lib64:/opt/common/cuda/cuda-12.1.1/lib prepend-path CPATH /opt/common/cuda/cuda-12.1.1/include prepend-path PKG_CONFIG_PATH /opt/common/cuda/cuda-12.1.1/pkgconfig setenv CUDA_HOME /opt/common/cuda/cuda-12.1.1 -------------------------------------------------------------------
Removing Modules in your Environment
If you want to remove a module because it conflicts or you want to clean up your environment you can by using the module rm <module> command.
Using Modules in Scripts
To use modules within a shell script or interpreted language you will need to load a file from /usr/share/Modules/init into your program.
Bash
. /usr/share/Modules/init/bash module add gcc
Tcsh
source /usr/share/Modules/init/tcsh module add gcc
Modules in Non-Interactive Shell Sessions
In non-interactive shell sessions (non-login shells), the Modules configuration environment will not automatically load. This will also occur if the OS version of the compute node you are scheduled on is different from the OS version of the submission node you are submitting the job from.
If you will need the use of Modules in non-interactive SLURM jobs, cross-OS jobs, or other similar sessions, you will need to include the following in your shell init scripts. For SLURM specifically, please ensure you include these statements after any #SBATCH directives in your submission batch scripts, otherwise these directives will not work.
Bash
. /usr/share/Modules/init/bash . /etc/profile.d/ummodules.sh
Tcsh
source /usr/share/Modules/init/tcsh source /etc/profile.d/ummodules.csh
Modules on RHEL9 Desktop Sessions
Because of changes made in GNOME between RHEL8 and RHEL9, the module command will not work on desktop sessions out of the box. In order to use modules in a shell opened from a desktop session, you must source the modules init script. See #Modules in Non-Interactive Shell Sessions for the required commands. For convenience, we recommend adding this to the top of your shell init file (e.g ~/.bashrc, ~/.tcshrc), this way it gets sourced automatically with each new shell.
Note that this issue does not affect RHEL9 SSH sessions, only sessions using the desktop GUI.
Additional Help
You can type module with no arguments for a full list of commands or man module for further information.