HPC cluster systems typically have a large number of software packages installed. Often there will be several versions provided for a package where it will be necessary for a user to choose between them. Equally, two different packages may clash with each other: for example, the commands for Intel MPI and Open MPI would overlap if simultaneously installed.
turing node we use the modules package to manage the user environment for the installed packages. This makes it simple to use different packages or switch between versions of the same package without conflicts.
To get a list of available packages, use:
To load a module to set up your environment to use a package you type:
module load <package>
replacing with the relevant module name. For example to load Matlab use:
module load matlab
To get a list of currently loaded packages:
To unload a specific module, use:
module unload <package>
<package> with the relevant
module name. For example to unload
module unload matlab
To unload all loaded modules, use:
Environment modules also support the concept of default versions. The default version, where it exists, is shown in the output of
module avail e.g.
module load gcc will load here
gcc8.3.0, since it is marked as
default. If you wish to load the
7.4.0 version then you will need to specify
module load gcc/7.4.0. For example:
$ module avail gcc ----------------------------- /usr/share/Modules/modulefiles/compilers gcc/4.9.3 gcc/5.4.0 gcc/6.3.0 gcc/7.4.0 gcc/8.3.0(default) gcc/9.2.0-c7 $ module load gcc $ module list Currently Loaded Modulefiles: 1) gcc/8.3.0 $ module purge $ module load gcc/7.4.0 $ module list Currently Loaded Modulefiles: 1) gcc/7.4.0
Sometimes we stick with an older version as the default, since a lot of people may still be using that version, and will require checking of scripts and communication to all users of the package. For popular packages, we rarely make the newest version the default one, due to the potential for introduction of incompatibilities or inconsistent results.
Some of the software provided by a module may in turn depend on software provided by another module. For example, a
aster tool implementation will require a bundle of tools and libraries needed. These cases may be handled by module dependencies. On Liger, the module system is set up to load dependent modules automatically rather than requiring users to satisfy the dependencies first. We see that loading this ASTER module also loads
python, lapack, intel, gcc
$ module load aster $ module list Currently Loaded Modulefiles: 1) gcc/4.9.3 2) lapack/3.6.1/gcc/4.9.3 3) python/2.7.12/gcc/4.9.3 4) intel/2015.3.187 5) aster/11.0.10