Turing: User instructions for the module command


The module command is there to respond most effectively to your specific needs: to set environment variables such as compilers, mathematical libraries and tools, without you having to look for them on the disks.  It enhances the environment variables according to the product which you would like to use (compiler, debugger, etc.).


module (avail [product] | load product[/version] | list | switch product/version1 product/version2 | display product[/version] …)

  • ''avail'':  lists the different products available and their versions
  • ''load'' loads the product in its default version (noted: default), if a version is not specified
  • ''list'':  lists the different products loaded and their versions
  • ''switch'':  changes the version of a product already loaded

product represents the choice of:

  • a work mode
  • a compiler
  • a library
  • an application or a tool

version represents the different versions of the same product, and can include:

  • default: Version by default. This is taken if you do not specify a version; the default version is generally the best adapted.
  • a number: Complete number of the version.

Initialisation of the module command

The initialisation of module is done implicitly in the general environment files. There is nothing which needs to be positioned to obtain access to the module command.                                                                                                                                                           

List of available products

Are you looking for a specific product such as a particular version of a library?  Do we have it for your use? To find the response to this question, use the command module avail:

$ module avail
----------------- /bglocal/fe/pub/Modules/IDRIS/modulefiles/environnement ------------------
compilerwrappers/no           modules/1.147
compilerwrappers/yes(default) modules/3.2.9(default)

----------------- /bglocal/fe/pub/Modules/IDRIS/modulefiles/bibliotheques ------------------
essl/5.1(default)        lapack/3.3.1(default)    pnetcdf/1.1.1
fftw/2.1.5               netcdf/4.1.3(default)    pnetcdf/1.3.1(default)
fftw/3.2.2               parmetis/3.1.1           scalapack/1.8.0(default)
fftw/3.3.2(default)      parmetis/3.2.0(default)
hdf5/1.8.9(default)      phdf5/1.8.9(default)

------------------ /bglocal/fe/pub/Modules/IDRIS/modulefiles/applications ------------------
espresso/4.2.1             espresso/5.0.2             namd/2.8
espresso/4.3.2             gromacs/4.5.5(default)     namd/2.9(default)
espresso/5.0.1(default)    lammps/2012.10.10(default)

--------------------- /bglocal/fe/pub/Modules/IDRIS/modulefiles/outils ---------------------
cmake/2.8.9(default)      tau/2.21.4(default)
papi/5.0.1(default)       totalview/8.11.0(default)

This list is permanently evolving.  (The above list is dated November 2012).   

Loading an application

To launch an application, it is mandatory to explicitly load the product before the execution by using the command module load:

$ module load namd

The module command generates an environment variable suffixed by EXEDIR which supplies the absolute PATH of the application. This variable needs to be positioned explicitly before the execution of the command runjob.  In fact, the command does not read the variable PATH.  This environment variable, suffixed by _EXEDIR, can be visualised as any other environment variable defined in a module by using the command module display :

$ module display namd

conflict         namd
setenv           NAMD_EXEDIR /bglocal/cn/pub/NAMD/2.9/bin
module-whatis    namd version 2.9

Implicit linking with a library

Your code calls the NetCDF library. Before launching the compilation, it is necessary to load the module corresponding to the library by using the command module load :

$ module load netcdf

The compiling and linking with NetCDF are done implicitly:

$ mpiifort -c call_netcdf.f90
$ mpiifort call_netcdf.o -o call_netcdf.exe


The NetCDF references will be found automatically at the link time because one uses module compilerwrappers set to yes by default which adds some hidden options (wrappers) to the native compilers. To see the options actually passed to the compiler, you can use the following compilation flags -display, -show, -#, -echo, -v :

$  mpiifort -c -display call_netcdf.f90
# Modules - Fortran compiler wrapper
# mpiifort is /opt/intel/impi/
# mpiifort -c call_netcdf.f90 -I/smplocal/pub/NetCDF/4.1.3/seq/include

$  mpiifort -display call_netcdf.o
# Modules - Fortran compiler wrapper
# mpiifort is /opt/intel/impi/
# mpiifort  call_netcdf.o -I/smplocal/pub/NetCDF/4.1.3/seq/include -L/smplocal/pub/NetCDF/4.1.3/seq/lib -Bstatic -lnetcdff -lnetcdf -lnetcdf_c++ -Bdynamic -L/smplocal/pub/HDF5/1.8.9/seq/lib -Bstatic -lhdf5hl_fortran -lhdf5_hl_cpp -lhdf5_hl -lhdf5_fortran  -lhdf5_cpp -lhdf5  -Bdynamic -lz


The executable built with the module command calls the libraries which are linked in static mode, unless stated otherwise in the specific documentation of the library.   It is not necessary, therefore, to launch module another time before the execution.

Explicit linking with a library

If you wish to find the native compilers and thereby disactivate the wrappers, you must proceed as follows:

$ module purge
$ module load compilerwrappers/no      (Must be the first load.)
$ module load netcdf

Following this, you must not forget to explicitly use the environment variables generated by module during the compilation and linking:

$ mpiifort -c $NETCDF_FFLAGS call_netcdf.f90
$ mpiifort $NETCDF_LDFLAGS call_netcdf.o -o call_netcdf.exe

You can visualise the environment variables defined at load time by using the command module display :

$ module display netcdf

conflict         netcdf
prepend-path     PATH /smplocal/pub/NetCDF/4.1.3/seq/bin
prepend-path     MANPATH /smplocal/pub/NetCDF/4.1.3/seq/share/man
prepend-path     WRAPPER_FFLAGS -I/smplocal/pub/NetCDF/4.1.3/seq/include
prepend-path     WRAPPER_CXXFLAGS -I/smplocal/pub/NetCDF/4.1.3/seq/include
prepend-path     WRAPPER_LDFLAGS -L/smplocal/pub/NetCDF/4.1.3/seq/lib -Bstatic -lnetcdff -lnetcdf -lnetcdf_c++ -Bdynamic -L/smplocal/pub/HDF5/1.8.9/seq/lib -Bstatic -lhdf5hl_fortran -lhdf5_hl -lhdf5_fortran -lhdf5 -Bdynamic -lz
setenv           WRAPPER_PATH /smplocal/pub/Modules/IDRIS/wrappers
prepend-path     PATH /smplocal/pub/Modules/IDRIS/wrappers
module-whatis    netcdf seq 4.1.3

Loading a product containing different versions

A product (application, library, tool, …) can offer several versions, or a hierarchy of versions, but has only one version by default (label default).  Here are two examples indicating the different possible syntaxes for loading a product:

  • The Quantum ESPRESSO application contains several versions :
$ module avail espresso
  ------------------------------- /smplocal/pub/Modules/IDRIS/modulefiles/applications --------------------------------
  espresso/4.2.1          espresso/4.3.2          espresso/5.0.1(default) espresso/5.0.2
  • To load the version espresso/5.0.1 (by default) you can use the following:
$ module load espresso
$ module load espresso/5.0.1

However, to load espresso/5.0.2, you must specify the version:

$ module load espresso/5.0.2
  • Another example: The HDF5 library contains 2 sub-versions (parallel mpi and sequential seq) :
 $ module avail hdf5
  ------------------------------- /smplocal/pub/Modules/IDRIS/modulefiles/bibliotheques -------------------------------
  hdf5/mpi/1.8.9          hdf5/seq/1.8.9(default)

The following syntaxes are authorised for loading the version by default hdf5/seq/1.8.9 :

 $ module load hdf5
 $ module load hdf5/seq
 $ module load hdf5/seq/1.8.9

To load hdf5/mpi/1.8.9, you can do the following: $ module load hdf5/mpi

$ module load hdf5/mpi/1.8.9

List of products loaded

$ module list
Currently Loaded Modulefiles:
  1) espresso/5.0.1            2) hdf5/seq/1.8.9(default)

Changing the version of a product already loaded

This is not possible, of course, unless an alternative version appears in the list given by module avail. For example, the Quantum ESPRESSO version by default is not suitable for you? You can replace it with another available version by using the argument switch of the module command.

$ module switch espresso/5.0.1 espresso/5.0.2

With this command, you will use Quantum ESPRESSO version 5.0.2, instead of version 5.0.1.

Secondary effects to be avoided

The use of the module command can generate messages on the standard output stdout. This is a behaviour which must be avoided if the command is placed in a file ~/.bashrc or ~/.tcshrc  because this is detrimental to behaviours of commands such as rsh or ssh. In a non-interactive shell, these messages can be disactivated by using the option -s :

$ module -s load netcdf