- Main page: Software
The Environment Modules package, or Modules, is a convenient tool to modify a user's environment. Modules allow to set or change different shell environment variables, such as
MANPATH, in a clean fashion. ACENET utilizes Modules to provide easy access to different pieces of software.
For every environment setting, there is a corresponding modulefile, which contains necessary instructions on how exactly a user's environment should be modified. The modulefiles can be loaded and unloaded dynamically and atomically, with the corresponding dependency and conflict resolution rules. This allows effective management of multiple versions of different applications and environments. Moreover, the Modules commands syntax is the same in every shell (whether it's
csh). You can find more information about Modules on the Modules website. The version of Modules installed at ACENET is a customized TCL v1.144.
See Usage tips below for important notes.
Here is an example to give you an idea how Modules work. Say, you want to get access to the Intel compilers, so you type
$ module load intel
Once the modulefile is loaded, your environment is properly configured giving you access to the Intel compilers binaries and the compiler man pages:
$ ifort $ icc $ man ifort
The modulefiles are organized in a hierarchy of files and directories. The top level directory corresponds to the name of a package, and everything below the top level corresponds to a version of that package like so:
Here are some examples:
intel/12.0.0.084, octave/3.2.4, openmpi/pgi/1.2.9
Note that all modulefile names at ACENET are specified in the lower case.
At each level of the hierarchy, there is usually a default modulefile or a default subdirectory. Users have the choice of loading modulefiles by their full name (
package-name/version), or by the name of a software package (
package-name), i.e. short name. In the latter case, the default at each nested level will be selected to determine which modulefile to load.
Usually, the default is either the latest or the most stable version of the package, and it's set at ACENET's discretion in order to maintain a consistent environment. Users are free to load explicitly whichever version they prefer, taking care of loading other required modulefiles beforehand, or unloading conflicting ones.
What is configured
Every modulefile contains only those changes to the environment that would be made if one followed the instructions provided by the developers of a software package (e.g. user guide, readme file, setup script, etc.). Users can inspect every module file with the following command
$ module show modulefile-name
In addition to that, only one environment variable is set. Its name is the capitalized name of the modulefile (without spaces or hyphens), and it contains a path to where the software is installed. For example, the modulefile
gromacs/4.5.5 sets the environment variable
GROMACS that contains the following path
/usr/local/gromacs-4.5.5. This environment variable can be used by users in different scripts or compilation options (see for example FFTW).
The general syntax to use Modules is as follows:
$ module [ command ] [ -t | -l ] [ modulefile... ]
You can get the list of all available commands by calling
module with no options. Here is a list of the most useful commands:
- Show currently loaded modules
avail [ modulefile... ]
- List all available modulefiles
- Load modulefile(s) into the shell environment
- Remove modulefile(s) from the shell environment
switch modulefile1 modulefile2
- Switch two modules, i.e. unload modulefile1 and load modulefile2. You can use either short of full names here.
- Unload all loaded modulefiles
- Display information about one or more modulefiles. The show command will list the full path of the modulefile(s) and all (or most) of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)
whatis [ modulefile... ]
- Display the information set up by the module-whatis commands inside the specified modulefile(s). If no modulefile is specified, all ’whatis’ lines will be shown.
help [ modulefile ]
- Print the usage of each command. If an argument is given, print the module-specific help information for the modulefile.
- Many software packages have several versions available. You can see all available modules with
module avail package-name.
- Before loading a modulefile in your submission script, try to load it in your shell interactively in order to determine which other modules are required to be loaded or unloaded first. Or, alternatively, you can use
module showto see conflicting and required modulefiles.
- If your login shell is
bashthen you can use the autocomplete feature on the command line for the modulefile names by pressing the Tab key. This will work for both loaded and unloaded modules.
- Please remember that if you are using
cshinside your submission scripts, then your current login shell environment (i.e. loaded modules) will not be inherited by your job at the submission time. Consider the two options below.
- You can put any
modulecommands into your dot shell profiles, for example, to get often used modules loaded automatically, or to unload certain modules.
- Alternatively, you can load necessary modules right in your submission script before calling the main application binary (this is the way ACENET recommends for the majority of packages installed ACENET-wide).
- Finally, if certain modules present complicated dependencies that conflict with your current environment, it may be easier to do
module purgefirst in your submission script before loading required modulefiles (see for example VASP).
- Do not forget that with most applications, if you compile a program with certain modules loaded, you will need the same modules loaded to run it.
Currently, the following modulefiles are loaded by default in every user's account:
Please check the User Guide to verify that your dot shell profiles are configured correctly.