Many softwares need special setup to run well. Often, these softwares suggest sourcing initiallization scripts, setting environment variables like
LD_LIBRARY_PATH, or modifying your shell configuration (e.g.
~/.bash_profile or even
~/.bashrc). This is a common source of errors, as different software installed on the machine can have conflicting requirements, and old settings can be unsuitable for newer versions of the same software. At the NSC you should not do this. Instead, you should use the module system, which has been designed to solve this exact problem.
NSC has a long list of software installed, and often in multiple versions to suit the needs of various user communities. The module system enables users to see what versions of what software are available, choose the ones they need for their work and have them set up correctly for their session, and not be bothered by all the rest of the software. In some cases, NSC also uses the module system to indicate what software versions are recommended to use, and which versions are recommended not to use.
Please see installed software for how to use the actual software made available through the module system.
To get acceess to a NSC provided software you load the corresponding module with e.g.
module add python/2.7.6. This makes the software available for the remainder of your session, e.g. adding the binaries to your PATH, the manual pages to MANPATH, etc. When you unload a module with e.g.
module rm python/2.7.6, the changes made to your environment by loading the module are all reverted, restoring the previous state of your environment. This is also done when you try to load conflicting modules; the previously loaded one is removed and the replacement is added.
Furthermore, every time you log out your list of loaded modules is flushed. This to ensure that each new session is unaffected by decisions in old ones (after all, the previous session could be days or months ago).
Modules can also be loaded inside batch job scripts using normal
module add ... commands, which is highly encouraged as it makes very explicit what software versions are used in the job. Not only does this help in debugging failed jobs, but it also makes jobs more reliably repeatable, since they no longer depend on what modules happen to be loaded at submit time (recall that the entire shell environment including module affected environment variables is recorded and preserved at batch job submission).
The module system is integrated with the NSC compiler wrappers so that binaries compiled against NSC provided libraries will use the exact same version of these libraries at runtime, and enables the NSC mpprun MPI launcher to launch it using the exact right version of the correct MPI launcher for the binary. This means that you should not need to remember what modules you had loaded at build time, and you do not need to load them again in later sessions when you to want to run the binaries you built in order for the binary to find the correct libraries.
This is contrary to how modules are set up to work at some other HPC facilities, where the loaded modules (or even the order of loaded modules) will affect the behaviour of compiled binaries, as this can cause different dynamic libraries to be loaded at runtime. In such environments the user must keep close track of what modules to load and in what order, to ensure that jobs will run successfully, possibly even requiring modules to be loaded and unloaded between commands in the batch job script depending on the combination of software that the job uses. This is not the case at NSC, where that information is stored in the binary itself at compile time using RPATH and tags.
For more detail please see the section on compilers.
As always, use the Tab key a lot to avoid having to type so much (bash completion).
|module --help||General help with module commands|
|module avail||List the available modules and recommendations|
|module add ...||Load the selected modules into your session|
|module list||List your currently loaded modules (will be flushed at logout)|
|module rm ...||Remove selected modules from your session|
[joel@triolith1 ~]$ module avail - Package -----------------------------+- Versions -+- Last mod. ------ /software/modulefiles/triolith: OpenFOAM/2.2.2 2014/01/13 11:45:59 OpenFOAM/recommendation 2014/01/06 7:14:35 R/2.13.1 2013/03/25 15:40:09 R/2.15.1 2013/03/25 15:40:19 R/2.15.3 2013/08/12 10:54:50 R/3.0.1 2013/09/05 18:05:47 R/recommendation default 2013/11/14 9:17:58 abyss/1.3.6-build01 2013/12/03 10:00:51 abyss/1.3.7 2014/01/23 13:30:00 ... vasp/5.2.12-11Nov11 2013/03/25 15:33:20 vasp/5.2.12-11Nov11-SNIC 2013/03/25 15:33:41 vasp/5.3.2-13Sep12 2013/03/25 15:33:57 vasp/5.3.3-18Dec12 2013/10/09 13:39:58 vasp/recommendation default 2013/11/14 9:17:58 ... [joel@triolith1 ~]$ module add vasp # Press Tab Tab Tab here to get suggestions vasp vasptools/0.2 vasp/5.2.12-11Nov11 vasptools/recommendation vasp/5.2.12-11Nov11-SNIC vasp-vtst vasp/5.3.3-18Dec12 vasp-vtst/5.3.12-13Sep12+3.0a vasp/recommendation vasp-vtst/5.3.2-13Sep12+3.0a vasptools vasp-vtst/5.3.3-18Dec12+3.0c vasptools/0.1 vasp-vtst/recommendation [joel@triolith1 ~]$ module add vasp/recommendation # Type "/r" then press Tab *************** NO MODULE LOADED ***************** ***** Please also specify desired version ******** *** i.e. use the full name with version number *** The recommended version of VASP is 5.3.2. Type 'module load vasp/5.3.2-13Sep12' to use that version. [joel@triolith1 ~]$ module load vasp/5.3.2-13Sep12 # Copy and paste