Environment modules provide a mechanism for managing the user's environment . In this way, a user can easily modify the working environment to comply with different compilers and applications. The module system, ensure that the correct versions of libraries, executables and environment variables are set, so that each application will find the necessary resources for its operation.

Metropolis, uses the the environment modules package ( to control the working and the development environment. Access to the modules environment is granted with the module command. The syntax of the module command is as follows:

module sub-command module-file-name

The most important sub-commands are:

  • list: lists currently loaded modules (active modules)
  • avail: lists all available modules in the system
  • load <module name>: loads one or more environment modules
  • unload <module name>: unload one or more environment modules
  • purge: removes all loaded modules
  • switch <module name> <module name>: exchanges one module for another
  • help <module name>: provides more help for a module (if available)
  • show <module name>: displays the module file itself
A complete list of the module command options is provided with the "module help" command.



Here are some simple examples on the module command (in the following examples the "%" sign stands for the standard shell prompt and after each command follows a typical output):
  • To get a list of all available modules:
% module avail
------------------------------------- /usr/share/Modules/modulefiles -------------------------------------
dot                  module-info          null                 use.own
module-git           modules              openmpi-compat/1.6.5

-------------------------------------------- /etc/modulefiles --------------------------------------------
boost/gnu                       gnu/4.8.2                  mpi/ofed/mpich2                scalapack/mpich2
boost/gnu-4.8.2              intel/compilers        mpi/ofed/openmpi-1.8.4     scalapack/openmpi
boost/gnu-ofed-mpich   intel/impi                 mpi/std/mpich-x86_64
boost/intel                     intel/ipp                    orca/3.0.3
boost/intel-impi            intel/mkl                   R/3.2.0

----------------------------------- /opt/mellanox/bupc/2.18.0/modules ------------------------------------

----------------------------------------- /usr/local/modulefiles -----------------------------------------
python/2.7.9             python/numpy-1.9.2-gcc   python/numpy-1.9.2-intel

  • To load a module file:
% module load boost/gnu-4.8.2
  • To list all loaded modules:
% module list
1) boost/gnu-4.8.2
  • To unload a module file
% module unload boost/gnu-4.8.2
  • Get more information about a module file (help):
% module help boost/gnu-4.8.2
----------- Module Specific Help for 'boost/gnu-4.8.2' ------------

boost/gnu-4.8.2:  - sets the Environment for the serial version of Boost C++ development libraries - GNU CC 4.8.2 version

  • To ispect the variables and settings provided by a module file:
% module show boost/gnu-4.8.2

module-whatis     Serial version of Boost C++ static development libraries - GCC 4.8.2 version
conflict     boost/gnu boost/gnu-ofed-mpich boost/intel boost/intel-impi
setenv         CFLAGS -I/usr/local/boost/4.6.2/gnu-4.8.2/include
prepend-path     LD_LIBRARY_PATH /usr/local/boost/4.6.2/gnu-4.8.2/lib

Using modules in scripts

It is possible to use your own script and incorporate the functionality of the module environment within the script. For example:

  • Perl:
#!/usr/bin/env perl
use EnvironmentModules;
module("load boost/gnu-4.8.2");
  • Python:
>>> import EnvironmentModules as EnvMod
>>> EnvMod.module(['load','blast+'])


Creating your own modules

You are encouraged to create your own modules if needed and/or share it with your group members or colleagues. It is a three step procedure:
  1. First, create a directory named "privatemodules" under your home directory (c)
  2. Create and place your own module files inside it.
  3. Load the "use.own" module (module load use.own) at login. In this way, the module system will always check the $HOME/privatemodules for module files.
If you need to share your modules with other group members or colleagues, the most efficient way to do that is to create the privatemodules directory into a shared directory (for example /scratch) and then use to ln -s command in order to create soft links from the  home directories of the users in question, pointing to the shared privatemodules directory:

ln -s /scratch/mydirectory/privatemodules $HOME/privatemodules



Modulefile commands: all the available documentation from the developer's page