Difference between revisions of "Modules Basic Usage"
Line 23: | Line 23: | ||
==Unloading a module== | ==Unloading a module== | ||
− | + | To remove a module, so its environment gets cleared run <code> module unload ncbi_blast </code> | |
− | |||
All modules are automatically unloaded when you log out of the HPC system, and in most cases, there is no need to use the unload command. | All modules are automatically unloaded when you log out of the HPC system, and in most cases, there is no need to use the unload command. | ||
Revision as of 19:08, 7 November 2022
Back to Modules.
Upstream Documentation
See the User Guide to Lmod for the upstream documentation.
Basic Usage
The minimal information required for using a standalone application at UFRC:
module
will output help information on running the module command. The module help includes all information described below.
Loading a module
- If you already know the name of the module, the only command needed to load the latest or the default version of the module and be able to execute the software is 'module load <application>'. For instance, if the module is called ncbi_blast, run the following command
module load ncbi_blast
An example of the recommended way to load modules would be:
module load ncbi_blast/2.2.28
instead of module load ncbi_blast
Lmod is automatically replacing "somemodule/1.0" with "anothermodule/2.0"
when you try to load another module, it means that the two environment modules can not be loaded at the same time. You will need to separate your workflow so that you you complete all of the steps for "somemodule", then do a "module purge", and then "module load anothermodule/2.0".From a technical standpoint, this is done because the two modules both provide some supporting software (e.g. Python, HDF5, CUDAToolkit, etc.) that conflict with each other. Allowing both to load would break the environment.
Unloading a module
To remove a module, so its environment gets cleared run module unload ncbi_blast
All modules are automatically unloaded when you log out of the HPC system, and in most cases, there is no need to use the unload command.
Showing loaded modules
module list
will show all currently active (loaded) modules.
Finding a module
When you need to find out whether a program is already installed user either 'module spider' to search through the module names or 'module keyword' to search through module description, tags, and keywords.
E.g.
module spider blast
will find igblast, multigeneblast, ncbi_blast, samblaster, and wublast
E.g.
module keyword smrt
will find pbsmrtpipe, smrtsv2, and also the pacbio (smrtlink tools) module, which module spider will not find.
A much more concise, but context specific table of available modules can be obtained with
module avail
The "module avail" command shows all currently accessible branches of the global tree of modules, which depend on what compiler and MPI implementation modules are loaded. The core branch is always shown, but we also have compiler (intel/10.1 and intel/11.1) and mpi (mvapich/0.9.9, mpich2/1.0.8, mvapich2/1.4.1, openmpi/1.2.7, and openmpi/1.3.4 in the intel/10.1 branch as well as mvapich2/1.5.1, openmpi/1.3.4, and openmpi/1.4.3 in the intel/11.1 branch) implementation specific and even python version specific branches of the module tree. The top line at each section shown by 'module avail' shows exactly what loaded module is responsible for enabling that branch of the module tree. Sometimes, to be able to load a module that you find using "module spider" you might have to go through the sequential steps of loading the respective branches. For instance, if you need to load the module for the "espresso" software that was built with MVAPICH2 support using Intel Compiler version 11.1 you would run
module load intel/11.1 mvapich2 expresso
Showing information about a module
module whatis app
will show a short listing of module specific information such as name, version, category, upstream url, and a short description.
module spider app/version
will show you the long description and the information on what versions are available for a particular application as well as what other modules have to be loaded to enable the loading of this module.
Swapping branches
To switch between different compiler and MPI implementation of a particular app or to gain access to a module that belongs to a particular branch run the following command to swap the old for the new branch
module swap old new
or if you loaded a particular version
module swap old/version new/version
If multiple versions of a particular app/version are available module will automatically reload those modules when you swap the branches, so you could seamlessly switch between a single-threaded version of an app you used for testing and an mpi version that will be used for a large-scale computing job.
Managing Module Collections
A very useful feature of Lmod is to save and restore custom collections of modules with module save
and module restore
as described in the user collections section of the User Guide. See the contents of a collection with module describe
and show a list of your collections with module savelist
.