Modules provide a great way to easily customise your shell environment, especially on the fly. The module command syntax is the same no matter which command shell you are using.
At login users will have modules loaded for PBS, Open MPI and the Intel Fortran and C compilers.
Use the module avail command to see the list of software for which your environment may be set up for you via the module command
module load xxx will load the environment settings required by the xxx software package. For example, module load dot will add the current directory to your command search path.
module unload xxx may then be used to remove extras added to the environment. This is extremely useful in situations where different package settings clash.
To automate environment customisation at each login, users can add module load commands to their configuration files (eg. if using tcsh: $HOME/.login file; if using bash: $HOME/.profile file). However users should beware! The whole point of module files is to set up the environment for the execution of applications. Since some applications can have incompatible environment requirements, loading several application modules in your shell’s configuration file is likely to lead to problems.
To use software package xxx in a csh, sh or bash batch job script:
Points to note:
- csh and tcsh batch scripts will have the module command available without any special care to be taken on your part.
- for bash batch scripts to work with module commands, the BASH_ENV environment variable needs to be set to $HOME/.bashrc. $HOME/.bashrc currently sources the appropriate /etc/bashrc file. Your default environment is set up so that this will work, so avoid changing it.
- sh is not recommended as contrary to the man page description of the invocation of a sh script, even with the ENV variable set to $HOME/.bashrc, it does not get sourced at the start of the script execution. This results in module command not found type errors. If you must use sh instead of bash you will need to source $HOME/.bashrc at the beginning of the script before any attempts to use module load commands.
We encourage the use of the PBS -lsoftware= flag to avoid any issues with licensing on nodes, or during upgrade of software. See the appropriate entry in Software for details of the expected name for this flag.
It is a mistake to load any module without specifying its version. You should never load a module without a version. The default version can be changed at any time without any notification and something may stop working. Always specify version when loading a module!
The following table is a subset of the module sub-commands.
To see all sub-commands, enter:
|module help [modulefile…]||Print the usage of each sub-command. If an argument is given, print the Module specific help information for the modulefile.|
|module load modulefile [modulefile…]||Load modulefile into the shell environment.|
|module unload modulefile [modulefile…]||Remove modulefile from the shell environment.|
|module list||List loaded modules.|
|module avail [path…]||List all available modulefiles in the current MODULEPATH. All directories in the MODULEPATH are recursively searched for files containing the modulefile magic cookie. If an argument is given, then each directory in the MODULEPATH is searched for modulefiles whose pathname match the argument. Multiple versions of an application can be supported by creating a subdirectory for the application containing modulefiles for each version.|
|module whatis [modulefile [modulefile…]]||Display the modulefile information set up by the module-whatis commands inside the specified modulefiles. If no modulefiles are specified all whatis information lines will be shown.|
|module keyword string||Seeks through the whatis information of all modulefiles for the specified string. All module whatis informations matching the string search will be displayed.|
User Defined Modules
Apart from the environment modules available in the system area, you can define your own modules using:
This will set up the $HOME/privatemodules directory with an initial module file called null. It will also change your MODULEPATH environment variable to ensure that the module command looks for the modules in your own area. Use:
for further information on writing your own modules.