Skip Navigation

Understanding Modules

To manage the complexity of the software environment, Ookami uses environment modules. Each module encapsulates particular software packages that are made available to users. This allows for separate toolchains and compiler environments to be installed on the cluster at the same time without causing errors. Each module file contains the information needed to configure the shell for an application, including all of the dependencies.

The main command to interact with modules is the  module command. To get an overview, execute the command:

module --help

The commands used most often are:

module list (returns a list of all the currently loaded modules)

module avail (returns a list of the available modules)

module [load | add] (adds module to the current environment)

module [unload | rm] (removes a module from the current environment)

module initadd (adds modulefile(s) so they start up automatically when logging in)

IMPORTANT: Some of the modules are listed as local while the others are listed as shared. Local modules are local to the login node. Shared modules are used throughout the entire cluster. 

Because Ookami contains nodes with different types of CPU architectures, some modules will be available on certain nodes and unavailable on the others.  For example, the Intel compiler module (intel/compiler/64/2020/20.0.2) is can only be used on nodes with x86_64 architecture. Likewise, the Fujitsu compiler module (fujitsu/compiler/1.0.20) is only available on aarch64 nodes.

In order to reduce confusion, the module avail command will, by default, only list modules that are intended to be used on the current node.  Modules that cannot be used on your current node will be hidden by default.  The exception to this is the login node, which will display all modules that are available across all nodes.

After logging on to Ookami, users setup their environment by loading modules as needed into the current shell. While it is possible to code this information directly into a .bashrc or .bash_profile, we tend to discourage users from doing this in order to fully utilize a modular environment.