Software modules make it easy for you to use software installed on CS servers. We provide a wide range of software across all our servers so that you don't have to install software on your own. We also offer different versions of software, letting users choose which they want to use.

Software modules modify Environment Variables unique to your shell. Environment variables include for example the variable PATH, which are directory path(s) to executables to use when typing a command in your terminal. For example, when you log in via SSH, variables such as the PATH variable are set or updated to contain the location(s) of various executable commands such as vim, sinfo, and others.

Each time you load a module, this variable and others are updated to make additional commands or libraries available to your shell.

If software is required but is not listed, please send an email to cshelpdesk@virginia.edu with the following information:

1. In the subject line, write: Software Module Request: <software name and version>
2. In the body of the email, include information about the requested software
   1. Links to software documentation page(s) if available
   2. Version(s) required

In January of 2025, the CS department is transitioning the backend software used for interacting with modules from Environment Modules to LMOD (LMOD Homepage), and implementing EasyBuild (EasyBuild Homepage) for maintaining modules.

• LMOD is a modern module interaction software that is commonly found in Linux based computing environments

• Interacts directly with EasyBuild so that modulefiles are integrated and managed easily

• Customizable options such as caching to improve speed for commands such as module avail

• EB automatically generates modulefile(s) when compiling software and allows for granular control for software builds
  • This allows our team to more quickly add/update available software as needed

• EB offers a large library of available software modules that can be compiled from prewritten compilation/build definition files
• These can be adjusted to fit specific needs and requests

• EB is commonly used in HPC environments, including UVA Research Computing, and thus can be used as an instructional tool

• EB compiles and creates software dependencies as modules themselves so that OS package dependencies are de-emphasized

• Software is compiled using a specific toolchain, such as a specific version of GCC. This means we can support software compiled with specific versions of GCC more easily and support multiple versions

The existing module system will be kept until approximately January 2026 and then fully removed thereafter. For information on how use the legacy system, click here.

Under this new system, there will be three primary types of modulefiles and available software

1. Common/Core
   • These are software modules compiled and maintained using EasyBuild
2. Custom
   • These are software modules that were manually compiled that are not available within EasyBuild or have another reason for manual compilation
3. Licensed
   • These are software modules that require some form of license to use (for example, matlab, gurobi, etc.)

• Generally, executing module purge before loading software or when switching modules is recommended. This ensures dependency modules are unloaded from other software(s) and only the software you want is loaded

• Module version suffixes now end with a slash character gcc/11.2.0 instead of a dash character gcc-11.2.0

• When a version is not specifed, the default will be loaded. Default modules are marked with (D) when using module avail

• Modules Renamed
  1. cuda-toolkit is now cuda
  2. cudnn-<version>_cuda<version> is now cudnn/<version>-CUDA-<version>
  3. python3 is now python/3.12.3, or simply python for the latest version available
  4. python2 is now python/2.7.18

• Modules Removed
  • These are modules that failed to compile, are presumed unused due to their age, or are not functional under the new system. If one is listed that is still required, please submit a request to cshelpdesk@virginia
  1. afl-2.57b
  2. apktool-2.3.2
  3. binutils-2.27.0
  4. clang-llvm-7.1.0
  5. clang-llvm-11.1.0
  6. cmake-3.15.2
  7. cmake-3.15.2
  8. cuda-toolkit-10.2
  9. cuda-toolkit-11.2.2
  10. cudnn-8.9.5_cuda11.x
  11. cppcheck-2.7
  12. dmd-2.088.0
  13. dmd-2.100.0
  14. doxygen-1.8.14
  15. edb-1.3.0
  16. emacs-25.3
  17. emacs-28.1
  18. fio-3.30
  19. git-2.37.1
  20. git-2.9.5
  21. go-1.19.1
  22. gradle-5.1
  23. gradle-7.5.1
  24. infer-0.17.0
  25. java18-18.0.1
  26. java8-1.8.0_202
  27. java8-1.8.0_371
  28. lammps-23Jun2022
  29. libav-12.3
  30. lua-5.3.6
  31. maven-3.8.6
  32. nano-6.0
  33. nano-6.3
  34. nccl-9.2
  35. nccl-10.2
  36. nccl-11.0
  37. nccl-11.8
  38. neovim-0.9.5
  39. nvhpc-20.7
  40. nvhpc-22.9
  41. nvtop-3.0.0
  42. openmpi-4.0.2
  43. perl-5.26
  44. pmix-2.2.3
  45. pmix-3.2.3
  46. python-2.7.15
  47. python-3.8.0
  48. python-3.10.11
  49. python-3.10.12
  50. python-3.10.13
  51. r-3.6.1
  52. rstudio-2022.07.2
  53. ruby-3.1.2
  54. rust-1.27.0
  55. rust-1.77.0
  56. sbt-1.2.8
  57. sbt-1.7.3
  58. scala-2.13.0
  59. scala-3.2.0
  60. scons-3.0.1
  61. sqlite-3.25.3
  62. swig-4.2.0
  63. tensorrt-8.6.1_cuda12.1
  64. tmux-2.3
  65. tmux-2.7
  66. valgrind 3.13.0 (now a local OS package install on each server)
  67. valgrind 3.20.0 (now a local OS package install on each server)
  68. valgrind 3.23.0 (now a local OS package install on each server)
  69. verilator-4.024

To switch to the legacy module system, execute the following

• Note, this makes the new EasyBuild module system unavailable to use to prevent software conflicts
• Note, all legacy modules may or may not function properly due to paths being updated

module purge
export MODULEPATH="/swlegacy/ubuntu/modules/modulefiles"

If you are submitting a SLURM job that uses the old modules, you will have to include this in your SBATCH scripts before any module load commands are used.

To switch back to the new system, simply log out and back in.

• What is the difference between gcc and gcccore?
  • GCCCore can be considered a base or core compiler used for compiling items such as CLang
  • GCC howver contains GCCCore and binutils
  • For any module that lists gcccore/<version> as a requirement, loading gcc/<version> will also work

• I'm unable to run module commands in a *ZSH* shell OR receiving the error compinit: function definition file not found. To solve this, execute the following command before starting your zsh shell
  • unset FPATH
  • zsh
  • source /etc/profile.d/modules.sh (this may not be necessary depending on your zsh configurations)

• LMOD FAQ Link

Modules are compiled using a toolchain such as gcc, the system default (i.e. what the server has available), or others. This means that modules compiled using a toolchain will not be available (i.e. won't be shown with module avail) until the toolchain has been loaded.

For example, openmpi will not show up in the module avail output until the appropriate GCC toolchain is loaded. Required modules can be found by using the module spider <module name & version> as shown below.

In-depth information about module usage and interaction can be found (here).

To list available modules

module avail

To load a default module (no version specified)

module load <module name>

To load a specific version, include the version suffix

module load <module name>/1.2.3

To search for modules and list required dependency modules to load certain modules

module spider <module name & version>

For example, to load python, first search for what python versions are available

module spider python
----------------------------
  python:
----------------------------
    Description:
      Python is a programming language that lets you work more quickly and integrate your systems more effectively.

     Versions:
        python/2.7.18
        python/3.10.8
        python/3.11.3
        python/3.12.3

Then, search for required modules to load first before loading a specific version of python

module spider python/3.12.3
----------------------------
  python: python/3.12.3
----------------------------
    ... output omitted ...
    You will need to load all module(s) on any one of the lines below before the "python/3.12.3" module is available to load.
      gcccore/13.3.0

Thus, gcccore/13.3.0 is required to load python/3.12.3

module load gcccore/13.3.0
module load python/3.12.3

Alternatively, you can load the required module and the module itself on one line

module load gcccore/13.3.0 python/3.12.3

To load the default version, simply omit the version

module load gcccore python

To show all currently loaded modules

module list

To show information about a module

module whatis <module name & version>

To unload a module

• Note, some module load multiple dependencies as shown with a module list command, which are not unloaded automatically. It's recommended to purge (unload all) modules instead

module unload <module name & version>

To purge (unload all) loaded modules

module purge

Before submitting a job, it is recommended to unload all loaded modules using module purge before and during the job launch, and then load them in the job script or at the command line for an interactive job.

This ensures that no unexpected modules are carried forward into your job from your shell's environment variables.

#!/bin/bash

#SBATCH --gres=gpu:1
#SBATCH --mem=16000
#SBATCH -t 04:00:00
#SBATCH -p gpu
#SBATCH --mail-type=begin,end
#SBATCH --mail-user=<computingID>@virginia.edu

module purge
module load gcc
module load python

python3 myprogram

For most Python related packages (i.e. pip install …), it is often more applicable to utilize a virtual environment. This can be done with Conda or venv. The former requires loading an miniforge module, and the latter requires the python3 module.

After loading and using this module, your ~/.bashrc file will be updated to source the base environment each time you log in.

After logging into portal, load the module and configure your shell to allow for conda activate commands

abc1de@portal01:~$ module load miniforge
abc1de@portal01:~$ conda init bash

// after logging out and back in
(base) abc1de@portal01:~$ conda create -n mynewenvironment

This will by default create an environment named mynewenvironment in ~/abc1de/.conda/envs/.

You can also specify a path where an environment should be created

(base) abc1de@portal01:~$ conda create -n mynewenvironment --prefix /p/myprojectdirectory/condaenvs

Packages can be specifed when creating an environment

(base) abc1de@portal01:~$ conda create -n mynewenvironment matplotlib=3.5 numpy=1.21

Environments can be created using a .yml file as well

(base) abc1de@portal01:~$ conda env create -f /<path>/env.yml

To list available environments

(base) abc1de@portal01:~$ conda env list

OR

(base) abc1de@portal01:~$ conda info --envs

To activate an environment (if the name is shown with conda env list)

(base) abc1de@portal01:~$ conda activate mynewenvironment

To activate an environment by path

(base) abc1de@portal01:~$ conda activate /<path>/mycustompathenv

After logging into portal, load the python module

abc1de@portal01:~$ module load python

To create a python3 venv envrionment

abc1de@portal01:~$ python3 -m venv /<path>/myvenv

To activate a python3 venv environment

abc1de@portal01:~$ source /<path>/myvenv/bin/activate

Commands such as pip3 can now be used within the envrionment

abc1de@portal01:~$ which pip3
/<path>/myenv/bin/pip3

abc1de@portal01:~$ pip3 install <package name>

A Jupyter Notebook interface can be loaded using a virtual environment (as described above). This is best done using a NX virtual desktop. Once you've logged into your NX virtual desktop, load python3 or miniforge as a software module:

abc1de@labsrv03~:$ module load miniforge

Then, load Jupyter Notebook:

abc1de@labsrv03~:$ Jupyter Notebook

Follow the link given to you by the Notebook Server to access the interface:

[W 12:52:23.489 NotebookApp] Loading JupyterLab as a classic notebook (v6) extension.
[I 12:52:23.492 NotebookApp] Serving notebooks from local directory: /u/abc1de
[I 12:52:23.492 NotebookApp] Jupyter Notebook 6.5.4 is running at:
[I 12:52:23.492 NotebookApp] http://localhost:8888/?token=eb9345040d71bbeb1eddc75fb88504f98e25beb207907f6d
[I 12:52:23.492 NotebookApp]  or http://127.0.0.1:8888/?token=eb9345040d71bbeb1eddc75fb88504f98e25beb207907f6d
[I 12:52:23.492 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 12:52:23.634 NotebookApp] 
    
    To access the notebook, open this file in a browser:
        file:///u/<youruserid>/.local/share/jupyter/runtime/nbserver-20880-open.html
    for example...
        file:///u/abc1de/.local/share/jupyter/runtime/nbserver-20880-open.html

Apptainer is the supported software for using containers throughout the CS environment. See our page on (Apptainer) for more information.