What are Modules?

Environment Modules - (referred to as just Modules) is the system the cluster uses to select which software to use. It also allows you to choose which version if multiple versions of a given software exist. Modules does this by adding software paths to your environment PATH variable.

Viewing Modules

To access the cluster resources and send commands you need to use an SSH client. On Mac and Linux, from the a terminal simply run:

ssh Your_NetID@hpc2.storrs.hpc.uconn.edu

(Where 'Your_NetID' is your own NetID consisting of 3 letters and 5 numbers)

For Linux/MacOSX users, it is recommended to set up and use SSH keys.

Windows users can login using MobaXTerm.

Once connected, you should see a terminal prompt like:

[Your_NetID@login4 ~]$

To view all available modules run the command:

module avail

This will list out the applications that you can load into your environment. We can also use it list the available versions for a specific program. For example, let’s say I want to load the newest version of python available. I could use the following command to see which versions of python are installed.

module avail python
-------------------------- /cm/shared/modulefiles --------------------------
python/3.7.3  python/3.10.5

Now, I need to take note of which python version I want to load. Let’s say I want python/3.10.5. Next we’ll cover how to load a module.

Loading Your Environment

To load a module, the command will follow a format like the line below.

module load {MODULE_NAME}

Where your module name is one from the list of available modules. You’ll just need to replace {MODULE_NAME} with the name and version of the module you want. For example, I could load python/3.10.5 with this command.

module load python/3.10.5

Note that tab completion works for the names of modules. So you could type “python/3.1” and then hit tab which would automatically fill in the rest of the version info.

You’ll see that when we ran the module load python/3.10.5 command, there were other prorgams loaded as well. That’s because python depends on other programs being loaded.

 module load python/3.10.5
  Loading python/3.10.5
  Loading requirement: gcc/11.3.0 tcl/8.6.12 sqlite3/3.39.0

To view all the loaded programs, you can run the command:

module list

In this python example, the output looks like this:

module list
Currently Loaded Modulefiles:
 1) slurm/slurm/21.08.8   2) gcc/11.3.0   3) tcl/8.6.12   4) sqlite3/3.39.0   5) python/3.10.5

It’s worth noting that some modules have conflicts because different versions of the same program cannot be loaded at the same time. For instance, if I tried to load the older version of python (3.7.3) right now, it would not load because of the conflict.

module load python/3.7.3  
  Loading python/3.7.3
  ERROR: python/3.7.3 cannot be loaded due to a conflict.
  HINT: Might try "module unload python" first.

As the hint suggests, I have to unload python first. To unload a module, use the following command:

module unload {MODULE_NAME}

For this specific python example, I can use this command and it will unload python as well as its dependencies.

module unload python
  Unloading python/3.10.5
  Unloading useless requirement: gcc/11.3.0 tcl/8.6.12 sqlite3/3.39.0

Now, we can load the older version of python successfully as shown below.

module load python/3.7.3
  Loading python/3.7.3
  Loading requirement: gcc/5.4.0-alt tcl/8.6.6.8606 sqlite3/3.18.0 libffi/3.2.1

Modules you use together frequently

Sometimes, there are certain modules that you use together frequently. It can be tempting to automatically load those modules in your ~/.bashrc file, but we urge our users to please not do this. This routinely leads to problems for users due to conflicting modules.

We get it though. It’s annoying to remember the versions and load the same modules multiple times a day. So, we suggest that users instead create a file containing those programs and then source that file anytime they need. For example, let’s say I need to load gromacs and all of its dependencies. I would make a file called load_gmx.

touch ~/load_gmx

Open the file with Vim.

vi ~/load_gmx

Press the letter i key on my keyboard so I can edit the document. Copy and paste the following commands into the terminal. These set the shell and load gromacs.

#!/bin/bash

module load gromacs/2022.3/gpu

Then I would save by pressing the <Esc> key and typing :wq. Now whenever I want to load gromacs, I would simply source that file.

source ~/load_gmx

And as you can see, all the 12 of the modules I need are loaded:

module list
Currently Loaded Modulefiles:
 1) slurm/slurm/21.08.8   3) hwloc/1.11.11   5) sqlite3/3.39.0   7) binutils/2.26   9) openmpi/4.1.4  11) cuda/11.6
 2) gcc/11.3.0            4) tcl/8.6.12      6) python/3.10.5    8) zlib/1.2.12    10) fftw3/3.3.10   12) gromacs/2022.3/gpu

To deactivate those modules, I could either use module unload gromacs or just start a new session on the cluster by logging out and logging back into HPC 2.0.

Making Your Own Module Files

A user can create their own module files, to load environment variables and paths. Create a directory in your home directory called privatemodules. This is where you will store your module files. The convention for creating module files is making a directory with the name of the application and a text file with the version number. For example, if you wanted a module file for gcc version 4.1.2, the directory would be:

~/privatemodules/gcc

and the file name would be 4.1.2 Below is a sample module file for GCC version 4.1.2 . You can use this as a basic template.

File content:

#%Module1.0#####################################################################
##
##gcc 4.1.2  modulefile
##
##Module to set up GCC 4.1.2
##
module-whatis "GCC 4.1.2"

conflict gcc
 
prepend-path    PATH                    /usr/local/pkg/gcc/4.3.6
prepend-path    LD_LIBRARY_PATH         /usr/lib/gcc/x86_64-redhat-linux/4.1.2
prepend-path    MANPATH                 /usr/share/man/

Notice a conflict is defined, so only one version of GCC can be loaded at a time. The environment variables are defined with the path they were installed to. Specific programs may require other environment variables. In this case the basic template is:

prepend-path   {VARIABLE NAME}         {PATH}

After saving this file, you may load it the same as with the cluster module files. Make sure you do not create a module with the same name as one already created. For example, if gcc/4.1.2 is taken, but you would like a user version of this, create gcc/4.1.2-1