Module Command

Contents:

Overview

The Environment Module approach has been adopted to help simplify the complex software requirements on UNT HPC systems. The Modules package provides a powerful command driven interface for modifying environments. This abstraction allows users to instantaneously modify software paths, library paths and other variables by 'load'ing and 'unload'ing different modules.

Usage

The following table lists frequently used commands:

Command Description
module avail List all modules currently available.
module list List all modules currently loaded into environment.
module help application Print Module specific help for application application. Without the application argument, module command usage will be displayed.
module load application Load all settings for application into current environment.
module unload application Unload all settings for application in current environment.
module initadd application Add application to the shell’s initialization file in the user’s home directory.
module initrm application Remove application from the shell’s initialization files.

Implementation Details

Caveats

Changing Shells

It is entirely possible to change shells of the same lineage e.g. sh->bash or csh -> tcsh without issue. However, expect a conflict when changing shells to a different lineage e.g. tcsh -> bash. The conflict being that the modulecommand is not known within the ksh because the startup files for each shell are lineage specific. The conflict can be resolved in 1 of 2 ways:

  • source /etc/profile.d/modules.sh either manually, or via your own login script as follows:
    typeset -f module > /dev/null
    if [ $? != 0 -a -r /etc/profile.d/modules.sh ] ; then
      . /etc/profile.d/modules.sh
    fi
  • force execution of the new shell as a login shell by using -llike:
    #!/path/shell -l

Versions

Often, there is more than one version of a module available. This normally means that one is set as the default version by administrators. This require the user to recognize this and if the default is not the desired version add the correct version to start up files via the module initadd application/X.X command

Module Classes

In an effort to help ensure module use is as simple as possible, the modules have been organized into classes. The following table details the class structure:

Name Purpose
compilers collection of compilers available
libraries development resources that provide services to other programs
mpi resources that provide the Message Passing Interface (MPI) to other programs
scientific end-user scientific applications
tools tools to assist with debugging, development, and tuning tasks
vis modules that provide applications and tools for visualization work

Examples

 

Loading a module:

$ module load mathematica
*Note: this is done silently

 

Unloading a module:

$ module unload mathematica
*Note: this is done silently.

 

List modules currently loaded in your environment:

$ module list
Currently Loaded Modulefiles:
1) mkl/10.2
2) intel/mpi/3.2
3) intel/11.1
4) openmpi/intel-qlc/1.2.8

 

List modules currently available:

$ module avail
------------ /usr/share/Modules/3.2.6/modulefiles ----------------
dot module-cvs module-info modules

---------- /usr/share/Modules/modulefiles/compilers --------------
intel/11.1

----------- /usr/share/Modules/modulefiles/libraries -------------
mkl/10.2