Difference between revisions of "Modules"
(→) |
|||
| Line 26: | Line 26: | ||
* swap a specific module for another one (especially useful to switch between different versions of the same program) | * swap a specific module for another one (especially useful to switch between different versions of the same program) | ||
| − | $ module switch x y | + | $ '''module switch x y''' |
Using these commands, the module system takes care of setting all the system and environment variables, so as to allow the desired applications to find themselves and all their prerequisites. | Using these commands, the module system takes care of setting all the system and environment variables, so as to allow the desired applications to find themselves and all their prerequisites. | ||
| Line 32: | Line 32: | ||
If you need lots of modules time and again, this loading can be automated with a [[sh-file]], so that you just have to execute the file once and it will load all modules you need. | If you need lots of modules time and again, this loading can be automated with a [[sh-file]], so that you just have to execute the file once and it will load all modules you need. | ||
| − | |||
| − | |||
== References == | == References == | ||
[http://modules.sourceforge.net/ Modules Homepage] | [http://modules.sourceforge.net/ Modules Homepage] | ||
Revision as of 15:18, 3 June 2019
The module system is a concept available on most supercomputers, simplifying the use of different software (versions) in a precise and controlled manner.
In most cases, a supercomputer has far more software installed than the average user will ever use. Each of these software packages need different settings in terms of $PATH, $LD_LIBRARY_PATH and other environment variables, which can adversely affect each other or even be mutually exclusive. Secondly, different user (groups) need different versions of the same software, which in general cannot be installed nor used in parallel on the same system.
Therefore, the settings for all these software packages and their supported versions are encapsulated in “environment modules” maintained by the module system. These modules are in no way related to 'perl' or 'python' modules and should not be confused with that.
By means of the module system, all software currently available on your cluster can be listed, loaded, and unloaded, by using the command module.
Usage
To get a list of all currently loaded modules:
$ module list Currently Loaded Modulefiles: 1) DEVELOP 3) intelmpi/2017.4 2) intel/16.0 4) likwid/system-default
detailing that from the category DEVELOP, the Intel Compiler ICC in version 16, the Intel implementation of MPI in Version 2017.4 and the system default version of Likwid are currently loaded and usable.
Calling
$ module avail
lists all available (loadable) modules and module groups. With the information of these two commands, one can:
- load a specific module
$ module load x
- unload a specific module
$ module unload x
- swap a specific module for another one (especially useful to switch between different versions of the same program)
$ module switch x y
Using these commands, the module system takes care of setting all the system and environment variables, so as to allow the desired applications to find themselves and all their prerequisites.
When there are multiple versions of the same program available, you can append /X.Y.Z to your "module load ..." command, exactly specifying what version number you want. In most cases, this is to enable backward compatibility (a prominent example being Compilers, where newer versions tend to break (or fail to compile) older programs).
If you need lots of modules time and again, this loading can be automated with a sh-file, so that you just have to execute the file once and it will load all modules you need.