Creating and maintaining a computing environment for a data analysis pipeline that consists of a large number of heterogenous tools, needs to be run by many users as must provide consistent data analysis results over a long time while frequent software upgrades and underlying operating system environment changes happen is not easy. Fortunately, the major points of this problem can be addressed by the use of an environmental modules system that abstracts the computing environment from the immediate data analysis steps. At the UF HPC we have chosen to implement this system using Lmod software written by Robert McLay at the Texas Advanced Computing Center (TACC).
Those who would like to learn as much as possible about lmod can use the documentation written by the Lmod author.
The minimal information required for using a standalone application at UF HPC:
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 it 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
Unloading a module
- To remove a module, so its environment gets cleared run
module unload ncbi_blast
A module often does not have to be unloaded when you are done using an application. When you log out of your HPC session all modules are automatically unloaded.
Showing loaded modules
will show all currently active (loaded) modules.
Finding a module
is a great time saver as it allow you to traverse the entire list of available modules along with short descriptions of the applications they make available. A much more concise, but context specific table of available modules can be obtained with
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 you 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 module load mvapich2 module load 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
module spider app/version
will show you the long description and the information on what versions are available for a particular application.
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.