Software Modules
The available modules for a specific software/package can be listed with the command module avail <package name> . This will list the available matches based on the keyword. Wildcard searching is also supported if you only know part of the package name.
[vega0051@ahl01 ~ ]$ module avail R/*rocky8
--------------------- /common/software/modulefiles/manual/common ---------------------------------------------------
R/4.2.0-openblas-rocky8 R/4.2.0-rocky8 R/4.3.0-openblas-rocky8 R/4.4.0-openblas-rocky8 R/4.4.2-openblas-rocky8
Loading Modules
module load <package name> will load the default version of the package into your session. If there is a specific module version that should be used instead, specify it with module load <package name>/<version>.
e.g.,
module load R/4.4.0-openblas-rocky8
After the module is loaded, it can now be called from the loaded environment. Loading modules will not automatically launch the software package.
The loaded modules can be checked anytime with module list.
Tip ml is a shorthand version of the module command and can be used to perform the same functions.
Unloading Modules
module purge will clear out all modules loaded in the current session. Individual modules can be unloaded with the command module unload <package name>.
Module Collections
Some workflows require loading in a number of modules into the session. Loaded modules can be saved into a module collection to easily retain the module set for future use.
After loading your modules, save the collection with module save <collection name>, in future sessions the modules can be restored with module restore <collection name>.
Saved collections can be listed with module savelist and individual collections can be inspected with module saveshow <collection name>.
Windows Software
Windows-only software can be accessed and run via the Windows Virtual Environment (Citrix). Once a Windows session is started, you access software applications in the same manner as if you were using a physical Windows computer.
Support Tiers
Software packages are marked with a support tier: Primary, Secondary, or Minimal.
Primary support is given to mature, popular scientific software important to a large fraction of the user base and generally receives the highest level of support. These software packages are compiled, installed, benchmarked, and documented as a service to users. They are tested after major system upgrades, new versions are installed in a timely manner, and MSI expects to be able to offer advice to assist with the majority of inquiries.
Conversely, Secondary or Minimally supported software are only useful to a very small number of users. These software packages may not be actively maintained, regularly updated, or tested after system updates. They may be removed without notice if usage is found to be too low to continue support.
“Depreciated” means that MSI had the software relatively recently, but for a variety of reasons, we no longer have it. For example, there might be licensing issues or conflicts with our cluster.
Need a Specific Package?
First, try installing it yourself in your MSI home directory following the guidelines below.
Software Installation Guide
Installing software on any Unix platform can be challenging for novice and veteran users alike.
While it is impossible to cover every issue you may experience, the following steps will allow you to compile and install many libraries and scientific applications in your own home directory.
Introductory Compiling
Building a Python interpreter from its source code is straightforward, requiring only a C compiler, and serves as an instructive example.
Installation materials are most commonly distributed as compressed tar files with the extension .tar.gz or .tar.bz. These files can be untarred and unzipped with the tar -xzf and tar -xjf commands, respectively. For example, if you downloaded Python-2.7.2.tar.gz to your home directory, the appropriate commands are:
tar -xzf Python-2.7.2.tar.gz
cd Python-2.7.2
Your next step should always be to review the distributed files for a README file or other installation instructions.
In many cases, and as is the case with Python, a configure script is included. In the simplest case, all that is necessary to compile the code is to run the configure script, then make.
By default many codes will try to install to system directories you cannot access. The recommended installation method is to create a directory in your home directory for software installation.
pwd
mkdir -v $SHARED/$USER/software
./configure --prefix=$SHARED/$USER/software/python
make install
When the make install step completes you will have access to the binary in:
/projects/standard/<project name>/shared/<UMN InternetID>/software/python/bin
Advanced Compiling
In many cases, it is necessary to use specific compilers and MPI libraries to build a working binary. See the quick start guides for details about the configuration of each HPC system.
Can’t get the install to work? Contact the MSI Help Desk for support.
Include a web link to the installation documentation for the package.
Will this package be used by several groups within MSI? Submit the Software Request Form and MSI staff will consider the functionality of the package, its usage, and how well it fits into MSI’s mission.
Private Software Modules
How can I Create Private Software Modules?
Software modules are used to manage the software environment on Linux systems, by allowing users to load and unload particular software versions. Loading a software module sets environmental variables in order to make a particular piece of software accessible. Many pieces of software have been installed and made available on MSI systems. To view the software modules available on a Linux system, use the command: module avail
Users can create private software modules, which allow them to load and unload software which has been installed within their home or group directories. The process for creating private software modules is described below.
First, choose a directory that will hold the private software module files. If the modules will be shared with other group members, place them in a directory for which the group members have read-access. If the modules will be used by a single user, the module files may be placed in a subdirectory of the user’s home directory. For example, the directory
~/modulefilesmay be used to hold a user’s private software module files.Prepend the module files directory to the MODULEPATH environmental variable using the command:
export MODULEPATH=~/modulefiles:$MODULEPATH
If you wish the private modules to be automatically available after every login, this command can be placed in the `~/.bashrc file`.
In the directory that holds the software module files, create a subdirectory with the name of the software package. For example, create the directory
~/modulefiles/MyProgram.Within the subdirectory named after the software, create a text file named after the software version. For example, create the text file
~/modulefiles/MyProgram/1.0. This file will be the software module file forMyProgram/1.0.Within the newly created text file, place the appropriate environmental alteration commands for making the software accessible. The language used in specifying these commands is the Tool Command Language (TCL). An example of a software module file is shown below.
#%Module
module load intel/2016/update3
set basedir ~/software/MyProgram
prepend-path PATH $basedir/bin
prepend-path LD_LIBRARY_PATH $basedir/lib
prepend-path CPATH $basedir/include
setenv OMP_NUM_THREADS 1
Module files should begin with #%Module in order for the system to recognize them as module files. Modules may load other modules, and in this example the module file loads the intel/2016/update3 module. The example module sets an internal variable named basedir to store the location of the directory containing the MyProgram installation. The prepend-path commands make the module add the referenced directories to the beginning of environmental path variables. For example, this module will prepend ~/software/MyProgram/bin to the PATH environmental variable, which will cause the system to search that directory for program files after the module is loaded. Similarly, the module adds library and include directories to appropriate environmental variables, to allow the system to locate library and header files. Finally, the module sets the environmental variable OMP_NUM_THREADS to the value of 1.
After these steps are taken, and a new module file has been created, the new private software module can be viewed and loaded. The module should be visible using the command module avail MyProgram, and can be loaded using the command module load MyProgram/1.0. The module can now be loaded and unloaded just like any other module. Unloading a module reverses the actions that the module performs when loaded. To view the actions the module takes when loaded, use the command: module show MyProgram/1.0.
The environmental alterations that a module needs to make are different for every piece of software. Some common alterations are prepending program directories to the PATH environmental variable, and library directories to the LD_LIBRARY_PATH environmental variable. Modules intended to be used when compiling often also need to have header include directories prepended to variables such as CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, FPATH, or INCLUDE, depending on the compiler and language. Other variables such as PYTHONPATH or R_LIBS can be altered to point to local Python packages or R libraries, respectively. The variable OMP_NUM_THREADS is commonly used to control how many threads an OpenMP program will spawn
Warnings
It is recommended to avoid creating modules with the same names as already-existing modules, as this can cause system confusion.
Some alterations to environmental variables can cause instability. In particular, altering LD_LIBRARY_PATH to point to directories containing dynamic libraries which conflict with operating system dynamic libraries can cause instability. In general, different versions of core libraries such as the C library (GLIBC), cannot be used without system instability.