Quest and Kellogg Linux Cluster Downtime, June 8th-14th, 2024.
Quest, including the Quest Analytics Nodes, the Genomics Compute Cluster (GCC), the Kellogg Linux Cluster (KLC), and Quest OnDemand, will be unavailable for scheduled maintenance starting at 7 A.M. on Saturday, June 8, and ending approximately at 5 P.M. on Friday, June 14. During the maintenance window, you will not be able to login to Quest, Quest Analytics Nodes, the GCC, KLC, or Quest OnDemand submit new jobs, run jobs, or access files stored on Quest in any way including Globus. For details on this maintenance, please see the Status of University IT Services page.
How to load and manage environment modules on Quest to access software.
Quest uses Environment Modules to give users access to the software installed on Quest.
Modules are used to manage:
- multiple versions of applications, tools and libraries
- software where complex changes to the environment are necessary
- software where name conflicts with other software would cause problems
Loading a module for a particular piece of software often adds the path to the executable to $PATH, the path to the library to $LD_LIBRARY_PATH, and so on. Loading a module, then, relieves the user of having to remember or look up and type long path names.
Looking for information on how to load specific applications or software on Quest through the module system? Please see our the list of available software and applications on Quest for further details.
Available Modules
Use the command
module avail
to list all modules available on Quest.
A listing of key software packages can also be found on the Quest Software page.
Loading a Module
To access almost every software application on Quest, you must first load the appropriate module:
module load <modulename>
Then you can reference software commands by name.
Module Versions
There are multiple versions of many software programs on Quest. Modules are named with the format softwarename/version. For example, if you look at the modules available for Python, you'll see several versions:
module avail python
---------------------------------------- /software/Modules/3.2.9/modulefiles -----------------------------------------
python/2.7.13 python/ActivePython-3.2 python/anaconda(default) python/anaconda3.6
python/ActivePython-2.7 python/Canopy python/anaconda3 python/epd-7.3-2
(default) indicates which module will be loaded if you don't specify the version (e.g. module load python). Defaults can change over time, however, so it is strongly recommended that you always specify the module version even if you are using the default version. For example,
module load python-anaconda3
Useful Module Commands
| Command |
Action |
| module avail |
Shows the available software packages |
| module avail <search> |
Shows all modules that have <search> in the main part of the name (not in the version, which comes after the /). <search> is case sensitive. This is useful for viewing the versions available for a particular program instead of having to sort through the long list of all modules. |
module -r spider '^p'
module -r spider mpi
module -r spider 'mpi$ |
Finds all the modules that start with `p' or `P'
Finds all modules that have "mpi" in their name.
Finds all modules that end with "mpi" in their name. |
| module list |
Shows which modules are currently loaded |
| module load <module> |
Loads a software package’s path information into your local environment so your session can find the software to run it |
| module purge <module> |
Takes the software package’s information out of your local environment; this is generally more reliable than module unload |
| module purge all |
Unloads all of the module packages currently in your local environment |
| module display <foo> |
Displays the changes that are made to the environment by loading module <foo> without actually loading it |