Skip to content

Environment Modules


Environment modules is available on Cori system

Environment modules provides a mechanism to dynamically modify users' environment via modulefiles. A modulefile is a recipe required to load a particular application that may include setting environment variables, set variables such as PATH LD_LIBRARY_PATH MANPATH to location where application is installed, load dependent modules and provide brief description of software.

Modulefiles are written in Tool Command Language (TCL) that is evaluated by module command when you load/unload modulefiles via module load or module unload.

What is module

module is a shell function that modifies user shell upon load of a modulefile. The module function is defined as follows

$ type module
module is a function
module () 
    eval `/opt/cray/pe/modules/ bash $*`


module is not a program

Module Commands


Cray default module is modules/ and documentation is based on this version

modules/ is also available to support non-Cray modulefiles that require Modules 4.x. While most modulefiles at NERSC should work with Modules 4.x, there are some compatibility issue with PrgEnv- modules, and we don't recommend modules/ for "normal" use.

General usage:

nersc$ module [ switches ] [ subcommand ] [subcommand-args ]

Further reading:

  • module --help
  • man module
  • man modulefile
  • Environment Modules Documentation (note: some features may only be available in later versions than what is installed on NERSC systems)

Command Summary

Command Description
module list List active modules in user environment
module av|avail [module] List available modules in MODULEPATH
module add|load [module] Load a module file in a users' environment
module rm|unload [module] Remove a loaded module from users' environment
module purge Remove all modules from users' environment
module swap|switch [module1] [module2] Swap module1 with module2
module show|display [module] Show content of commands loaded in module file
module help [module] Show help for a given module
module whatis [module] A brief description of the module, generally single line
module use [-a] [path] Prepend or Append path to MODULEPATH
module unuse [path] Remove path from MODULEPATH
module keyword [text] Search for keyword across all module files

Module Usage

Show availability of all modules containing a substring:

module avail -S <substring>

Display what changes are made when a module is loaded:

module display <module-name>
module show <module-name>

Add a module to your current environment:

module load <module-name>
module add <module-name>


This command is silent unless there are problems with the module.


If you load then generic name of a module, you will get the default version.

module load gcc

To load a specific version use the full name

module load gcc/8.1.0

Remove module from the current environment:

module unload <module-name>
module rm <module-name>


This command will fail silently if the specified module is not loaded.

Switch currently loaded module with a new module:

module swap <old-module> <new-module>
module switch <old-module> <new-module>

To purge all modules::


This will remove all your modules from active environment including startup modules loaded in your shell. To restore your environment with startup modules, its best to relogin

module purge

To view help for a particular module::

module help <module-name>

The module whatis command will display a brief summary of module whereas module help will provide the full description of modulefile.

$ module whatis PrgEnv-cray 
PrgEnv-cray          : Programming environment using the Cray CCE compilers.


Some modules may not have a help or whatis section in modulefile so you will see an empty line when you run module help or module whatis

To see a condensed list of module you can use module -t and use this with list or avail

$ module -t list
Currently Loaded Modulefiles:

At NERSC we have three Cray PrgEnv- modules: PrgEnv-cray, PrgEnv-gnu and PrgEnv-intel (the default). These modules provide respectively the Cray, GNU or Intel compiler via the compiler wrappers cc (C) CC (C++) and ftn (Fortran). You can only have one PrgEnv module loaded at a time: for instance if we load PrgEnv-gnu without first unloading PrgEnv-intel we get the following message.

    $ module load PrgEnv-gnu
    PrgEnv-gnu/6.0.5(77):ERROR:150: Module 'PrgEnv-gnu/6.0.5' conflicts with the currently loaded module(s) 'PrgEnv-intel/6.0.5'
    PrgEnv-gnu/6.0.5(77):ERROR:102: Tcl command execution failed: conflict PrgEnv-intel

To circumvent this you must swap or unload modules as follows

    # swap modules
    module swap PrgEnv-intel PrgEnv-gnu

    # unload + load
    module unload PrgEnv-intel
    module load PrgEnv-gnu

Creating a Custom Module Environment

You can modify your environment so that certain modules are loaded whenever you log in.

The first option is to use shell commands.


In ~/.bash_profile

module swap PrgEnv-${PE_ENV,,} PrgEnv-gnu


In ~/.login

set pe = ` echo $PE_ENV | tr "[:upper:]" "[:lower:]" `
module swap PrgEnv-${pe} PrgEnv-gnu


The second option is to use the "snapshot" feature of modules.

  1. swap and load modules to your desired configuration
  2. save a "snapshot" with module snapshot <snapshot-filename>

Then at any time later restore the environment with module restore <snapshot-filename>.

Install Your Own Customized Modules

You can create and install your own modules for your convenience or for sharing software among collaborators. See the man modulefile or the modulefile documentation for details of the required format and available commands. These custom modulefiles can be made visible to the module command by module use /path/to/the/custom/modulefiles.


Global Common is the recommended location to install software.


Make sure the UNIX file permissions grant access to all users who want to use the software.


Do not give write permissions to your home directory to anyone else.


The module use command adds new directories before other module search paths (defined as $MODULEPATH), so modules defined in a custom directory will have precedence if there are other modules with the same name in the module search paths. If you prefer to have the new directory added at the end of $MODULEPATH, use module use -a instead of module use.

Known issues with modules

Zero exit code for invalid modules

$ module load X
ModuleCmd_Load.c(244):ERROR:105: Unable to locate a modulefile for 'X'
$ echo $?

This means that module commands often return a "success" code (0) even if the command failed, which can lead to surprising errors in eg job scripts.

Incompatibilities with modules/

modules/ is available but not recommended. If you do need Modules 4.x, you can access it with module swap modules modules/ (note that module load modules/ will abort with an error). If using Modules 4.x, we recommend carefully checking that your script or usage has the correct outcome.

Please refer to for summary of difference between module v3.2 and 4.x

Module FAQ

  1. Is there an environment variable that captures loaded modules?

Yes, active modules can be retrieved via $LOADEDMODULES, this environment variable is automatically changed to reflect active loaded modules that is reflected via module list. If you want to access modulefile path for loaded modules you can retrieve via $_LM_FILES

  1. How to restore MODULEPATH in user session?

If you run into an error such as following::

$ module avail
ModuleCmd_Avail.c(217):ERROR:107: 'MODULEPATH' not set

You should try a new login shell and see if it fixes the issue. Check to see if your startup scripts (~/.bashrc, ~/.bash_profile) or ~/.cshrc for tcsh/csh