Modules are a method of modifying your environment that are unique to some software you're trying to run. It allows you to quickly switch between different programs or different versions of the same program.


Please refer to the cluster specific sections on KLONE [link] and MOX [link] below for more details on creating your own modules.

What software is available?#

module avail

The research computing team will maintain most of the core modules for building software, this includes GNU compilers (e.g., gcc, g++, gfortran) or their Intel compiler equivalents as well as select MPI libraries.

There is a larger list of modules maintained by the broader HYAK community that appears when you run this command. Community created or "contrib" modules are provided as is. Community modules on KLONE are separated into a lower section and within the lower section each module is further prefixed by the respective group that created the module. All modules appear together when you run this command on MOX but the community provided modules appear with a "contrib" prefix.


The HYAK team encourages the use of Apptainer to better promote computational portability and reproducibility. You can read more about Apptainer [link] after loading its module.

What modules do I currently have loaded?#

module list

How to (un)load a software?#

Replace "software" below with a specific module you know exists or identified via module avail above.

module load <software>

Conversely, you can unload a specific module.

module unload <software>

You can unload every module you might have loaded.

module purge


The KLONE cluster uses the more feature-rich LMOD implementation of modules. You're welcome to email us if you have any questions about modulefile creation on KLONE.



LMOD [documentation] [project page] is an upgraded implementation of environment modules created by the Texas Advanced Computing Center (TACC) at the University of Texas.

Login vs Compute Node#

Modules are meant to be set up for programs used in intensive computing; they should only be loaded on compute nodes. To reinforce this point the modules command does not exist on the login nodes. If you try to run the module command you will receive a warning message. This warning is benign and you can even disable it if you have modules loading in your start up shell file (e.g., .bashrc, .zshrc).

If you wanted to be more discerning, the logic is useful to include in your start up shell file for identifying if the host is a login node then running certain commands only if this is the case (or not).

export LOGIN_NODE=$(hostname | grep -q '^klone1' ; echo $?)
if [[ $LOGIN_NODE ]]
echo "This is a login node"
echo "This is a compute node"

How do I create personal LMOD modules on KLONE?#

This advanced user documentation page from the LMOD developers walks you through this [link]. You need to compile your code separately first. In short, you provide a command directing it to the folder with your collection of module files:

module use /path/to/personal/modulefiles

In this case you'll likely use a sub-directory under your lab's /gscratch folder or your home directory and create individual folders with independent software packages. Once you have code compiled a modulefile needs to be created for each software package you installed, there are some examples from basic to advanced [link].

How do I create shared LMOD modules on KLONE?#

Each group has a special folder for installing codes that are intended to be shared for all KLONE users. Each folder here gets a 100GB block quota and 160,000 inode quota at /sw/contrib/mylab-src where "mylab" is your account affiliation. We can raise these limits if specific code compiles require, however, in our experience the default quotas are sufficient for all but the most rare cases.

You place your modulefiles in /sw/contrib/modulefiles/mylab and when anyone runs module avail it will now appear in the "contrib" section in the lower half. Note the prefix is automatically tagged to your group name for you to more easily identify the ones you contributed (and likely will use most regularly).


The MOX cluster uses an simpler implementation of modules called environment modules. You're welcome to email us if you have any questions about modulefile creation on MOX.

Environment Modules#

Environment modules

Environment modules [documentation] [Wikipedia] has a long development history going back to the 1990's. It's still in use today due to its simplicity and ease of deployment for cluster administrators and end users alike.

How do I create my own environment module on MOX?#

Compile your code under /sw/contrib/ then create a modulefile under /sw/modules-1.775/modulefiles/contrib/ and it will appear when you run module avail. There are existing modulefiles there you can use as a template for creating your own.


Any contrib modules on MOX are provided and maintained by the local research community. Since no one except the original authors can vouch for the software supply chain provenance, anything under contrib is made publicly available as-is without any support, warranty, or guarantees.