Environment Modules
Environment modules is how we are able to provide one installation of a piece of software to an entire cluster and its user base. Modules also allow us to have infinite versions of a single piece of software without conflicts. A module is a piece of software that the user can load in his/her shell, and then have access to that software. The software is installed elsewhere, but is not available until the user loads it. Unity uses lmod for managing modules.
Using modulefiles is very simple. Keep in mind that the below commands will work anywhere on the cluster, so you can load/unload modules within your slurm submission scripts or during interactive jobs. This is what they are intended for.
List All Available Modules
module avwhich will return an output that looks something like this:
------------------------------------------------- /modules/modulefiles ------------------------------------------------- R/3.6.2 cuda/10.1.243 (D) gcc/9.2.0 julia/1.1.1 openmpi/4.0.4 cmake/3.7.2 cuda/11.0.1 glxgears/1.0 jupyter/3.6.8 python/2.7.16 cmake/3.15.0 (D) fd3dspher/1.0 gmsh/4.4.1 mathematica/12.0 python/3.7.4 (D) cuda/8.0.61 gcc/5.5.0 gpu-burn/default mesa/19.0.8 qt/5.13.1 cuda/9.0.176 gcc/6.5.0 gromacs/2020.2C miniconda/3.7 stress/1.0.4 cuda/9.2.148 gcc/7.4.0 (D) gromacs/2020.2G (D) opencl/2.2.11 vtk/8.2.0
URI Specific modules
More modules can be found by using module load uri/main. The modules under the heading/modules/uri_modules/allshould closely match the naming scheme used on
Illegal Instruction, then this is likely the issue.
Searching for Modules
module av gccThat will only show you the available gcc modules.
Loading Modules
module load gcc/9.2.0The convention is <app name>/<app version>.
After loading a module, you can test is out by running whereis gcc, which will show you which gcc will be executed.
Unloading Modules
module unload gccUnloading All Modules
module purgeList Currently Loaded Modules
module listHow it Works
You can skip this part if you don’t care about how it works, but it may allow you to gain a better understanding for future reference.
Environment modules work by modifying the user’s environment. The user’s environment has a number of variables set. To see them all, just runenvin the cli if you are curious. Those variables dictate what the user has access to. For instance, consider the$PATHenvironment variable. This variable is what determines where to find executable binaries. For example, when you run the commandlsto list the contents of your directory,lsis simply an executable that lies somewhere on the system. In this case,/bin. Ordinarily, to run thelsexecutable, you would need to reference it directly, i.e.,/bin/ls. To simplify this, linux adds certain directories to the$PATHenvironment variable. Any binaries/executable contained within any directories defined in$PATHcan be executed from anywhere directly, i.e.,ls. As such,/bin,/usr/bin,/usr/local/bin, etc. are all members of the$PATHvariable.
Modulefiles work by manipulating these variables. For example, considerpython, a binary that comes with almost all linux distributions these days. Usually, runningpythonwill execute the python that is installed on the system. But if we wanted to create a module which loads a different python, we would add the location of the different python into the environment variables, at the top of the list. Now, when you runpython, the first entry in$PATHdirects you to the module you loaded, and it loads that, even though a systempythonexists later on. The important thing is that the program you want to use is first in the variable.