Modules provide a way for a dynamic modification of a user's environment via modulefiles. They are very useful in managing large numbers of applictions, especially when there are multiple versions and dependencies present.
Each modulefile contains the information needed to set up your environment for the application.
In most cases it will alter or define shell variables such as
module and ml¶
ml is essentially an alias for module although
module list and
ml <package> means
module load <package>.
Finding available software¶
You are likely to have an idea of the software you want to use, the "ml spider" command will allow you to see available modules that fit the named package
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
To set-up your environment for a specific software you need to
relevant modulefile. The command should include the name of the application
and the desired version
If an application has dependencies such as libraries, compilers, etc, those will be automatically loaded for you.
We recommend that you always include relevant
module load statements in
your job scripts.
You can check which modules are currently enabled within your environment with
This should result in an output like:
1 2 3
If you are used to using Rosalind you may notice fewer modules are loaded.
This is due to the new packaging system which makes greater use of
RPATH for making dependencies available to a module.
You can remove any modules loaded within the current session using
module unload or
You do not need to explicitly unload modules when your job, or session terminates. The changes made by the module files are temporary and will only last for the duration of the job/session.
If you want to remove all of the currently loaded modules, use
Purging might remove utility modules loaded as part of your shell set-up/login process.
Finding out more about specific module¶
You may be able to find out more about a particular module by running
module what-is command:
Listing available software¶
To list all software available on the cluster use
This should produce something similar to
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
spacebar key to paginate through the list.
(D) tag next to the module names indicates the version
of the software that will be loaded if no explicit version has been
provided during the module load, e.g.
module load apps/matlab.
To avoid surprises when the defaults change, we recommend using explicit version numbers when loading the modules.
In some cases the same version of the software might be offered with different
build options, for example
python/3.9.12-gcc-10.3.0 will refer to a
version built using gcc
10.3.0 with python
Choose the version that is the most appropriate for your needs.
In some circumstances, especially if you build your own software, you might benefit from your own environment that integrates with the modules ecosystem. Details of how to run personal modules will be here soon...