Environment Modules

The Environment Modules module utility provides an effective way to control a set of BASH environment variables (such as PATH or LD_LIBRARY_PATH) to allow switching between application version in a very easy and controlled manner. By default, the latest versions of various development tools (for example oneAPI components) is configured in your environment. If you want to use an older version of a compiler or library you can use the module utility to manage the specific version you need.

General overview

Typical workflow while using modules includes the following steps.

• list available modules

~$ module avail
----------------------------------------------------- /glob/module-files/development-tools -----------------------------------------------------
bison/3.7(default)  cmake/3.21.2(default)  gawk/5.1.0(default)  gcc/11.2.0(default)   ninja/1.10.2(default)  tmux/3.2a(default)
cmake/3.16.3        emacs/27.2(default)    gcc/10.3.0           hdf5/1.12.1(default)  pdsh/2.34(default)

-------------------------------------------------- /glob/module-files/intel-oneapi-components --------------------------------------------------
advisor/2021.2.0        debugger/latest         init_opencl/2021.3.0        intel-rkutil/1.1.0                   mkl/2022.0.2
advisor/2021.3.0        dev-utilities/2021.2.0  init_opencl/2021.4.0        intel-rkutil/1.2.0                   mkl/latest
advisor/2021.4.0        dev-utilities/2021.3.0  init_opencl/2022.0.2        intel-rkutil/1.3.0                   mkl32/2021.2.0
advisor/2022.0.0        dev-utilities/2021.4.0  init_opencl/latest          intel-rkutil/1.4.0                   mkl32/2021.3.0
...
reducted
...
------------------------------------------------------- /glob/module-files/intel-oneapi --------------------------------------------------------
2021.2  2021.3  2021.3.0  2021.4  2022.1.2  latest

This lists a lot of modulefiles for some of the common development tools, various version of individual oneapi components and complete oneapi releases.

• load a module (we use cmake only as an example here):

~$ module load cmake/3.21.2
~$ which cmake
/glob/development-tools/versions/cmake/3.21.2/bin/cmake
~$ cmake --version
cmake version 3.21.2

Note that after loading this module, an expected version of cmake (3.21.2) is available in the PATH.

• show a list of currently loaded modules

~$ module list
Currently Loaded Modulefiles:
 1) cmake/3.21.2(default)

• if a different version of a package (cmake in this example) is needed, unload current version and load required version

~$ module unload cmake/3.21.2
~$ module load cmake/3.16.3
~$ module list
Currently Loaded Modulefiles:
 1) cmake/3.16.3
~$ cmake --version
cmake version 3.16.3

Once again, a version that is needed, is available with a very minimal effort. Alternatively, instead of module unload/load you can use module switch syntax:

~$ module switch cmake/3.16.3 cmake/3.21.2

• To unload all modules and obtain clean environment use

~$ module purge

• some other useful module commands are:

module show <module_name>
module whatis <module_name>
module help

Managing oneAPI releases with modules

MODULES can be used to control access to different versions of oneAPI in exactly the same way. The following example illustrates a typical usecase: first set the environment to use oneAPI release 2021.4 and then switch to oneAPI release 2022.1.2

~$ module load 2021.4 
~$ which icc
/glob/development-tools/versions/oneapi/2021.4/inteloneapi/compiler/2021.4.0/linux/bin/intel64/icc
~$ module switch 2021.4 2022.1.2
~$ which icc 2022.1.2
/glob/development-tools/versions/oneapi/2022.1.2/oneapi/compiler/2022.0.2/linux/bin/intel64/icc