Loading and initializing software modules
On the Lichtenberg HPC, various compilers, (scientific) libraries, and other (application) software are installed and readily available, often in different versions. Each of these software packages needs different settings in terms of
$LD_LIBRARY_PATH and other environment variables, which can adversely affect each other or even be mutually exclusive.
The settings for all these software packages and their supported versions are encapsulated in environment modules maintained by the LMod module system. These modules are not related to
Python modules and should not be confused with those.
By means of the module system, all software currently available can be listed, loaded, and unloaded, by using the command module.
With the module command, you can explicitly address particular versions of a module by giving the full name (e.g., gcc/9.2.0 or fftw/3.3.8), or use the short forms (e.g., gcc or fftw). When using this short form, you address the version that is currently set as default (indicated by a
(D) in the list of all modules).
Many modules depend on a compiler or an MPI implementation. These modules cannot be loaded directly -- instead, they become available only after loading a compiler and an MPI module (see
module spider to find these dependencies).
module load Module_Names
Loads the named software module(s). Only after this command (and when all other required modules have been loaded), the software becomes available to you.
module unload Module_Names
Unloads the named modules. From this time on, the corresponding software is no longer usable.
Shows all software modules that can currently be loaded, depending on which other modules are (not yet) loaded.
module avail Module_Name
Shows all available versions of the given software.
For example with module avail gcc, all available versions of GCC will be listed
Lists modules currently loaded
module help Module_Names
Shows the detailed description (if any) of the named module(s).
Lists all subcommands of
module whatis Module_Names
Shows the short descriptions of the named modules.
Shows all modules in the module system (whether currently loadable or not).
module spider Module_Names
Lists all available incarnations of this module. When specifying the version in the module name (“
ml spider Module/Version”), it lists all combinations of prerequisites in which this module version is available.
module switch Module_Namenewor
module switch Module_Nameold Module_Namenew
Replaces the previously loaded (old) module version by the named version (new). Similar to the pair module unload / module load, but keeping the former order of the loaded modules.
Unloads all currently loaded software modules.
Recommended for job scripts before all “
module load” commands, so as to start your jobs with a clean and reproducible environment.
- ml (without parameter) =
- ml Module_Name(s) =
module load Modul-Name(s)
All batch jobs you submit will inherit the currently loaded modules of your login session! It is thus good practice to begin your job scripts always with “
module purge”, followed by only the “
module load … …” commands necessary for this job. This way your jobs always run with a clean and reproducible environment.
- how to load modules automatically at login
- how to put together “collections” of certain modules, to be loaded time and again in one line.
Visibility and availability of conditional modules
Many software and libraries depend on a compiler or an MPI implementation. Their modules can thus not be loaded directly--instead, they become available only after loading a compiler and a mpi module.
module avail“ command will list only those modules you can currently load—dependent on what other modules are (not yet) loaded.
Therefore, some programs and libraries will show up only after loading a compiler and perhaps a MPI implementation. Some loaded modules will be amended (or even be getting new functionality) after loading other modules.
To find those “initially hidden” modules nonetheless, you can use the command „
module spider“, showing all modules in the module system.
Another way is adding
--show_hidden to “
module --show_hidden avail fftw
which will again list all modules named “fftw” in the whole module tree.
Example: according to „
module spider“, there is the
fftw module. In the list given by „
module avail“ however, it will not show up, unless you load a compiler (via „
ml gcc“ or „
ml intel“). After having loaded a compiler module, „
ml fftw“ will give you exactly the
fftw binaries compiled with that compiler.
In case you load
intelmpi (before or after loading
fftw), the loaded
fftw will be replaced by the respective MPI-capable
fftw (still based on the very same compiler).
in order to find out which modules are required by
fftw, you should use the
module spider fftw command.
Please don't hesitate to contact us in case of problems with modules--we are happy to assist.