Module Collections and Defaults

Last updated on 2026-08-27 | Edit this page

Estimated time: 25 minutes

Overview

Questions

  • How do I load multiple modules together?
  • How do I switch between different versions of the same software?
  • How can I save my module configuration and reload it later?
  • How do I use modules in batch job scripts?

Objectives

  • Load multiple modules for complex workflows
  • Use module swap to switch between versions
  • Use module purge to reset to a clean state
  • Create and manage personal module collections
  • Write module commands in SLURM job scripts

Loading Multiple Modules


Many research workflows require multiple pieces of software:

BASH

$ module load openmpi gaussian miniconda3 ncbi-blast
$ module list
Currently Loaded Modules:
  1) openmpi/4.1.5_ucx-1.14.0    2) gaussian/16c01_avx2    3) miniconda3/py313_26.3.2-2    4) ncbi-blast/2.13.0+
Two panels. On the left, saving a set you use often: load the modules you want, for example miniconda3 and cuda/12.2.1, then run module save myproject. On the right, restoring it later: module restore myproject loads everything at once. Notes mention module savelist and module describe, and warn that collections are per-user and do not carry into a SLURM job unless restored there too.
Save the set once, restore it in one command afterwards.

Swapping Module Versions


To switch between software versions, use module swap:

BASH

$ module load cuda/11.8.0
$ module swap cuda cuda/12.2.1
$ module list
Currently Loaded Modules:
  1) cuda/12.2.1

The swap command unloads the old version and loads the new one in a single operation, which is cleaner than separate unload/load commands.

Resetting Everything: module purge


If you load many modules and need to start fresh:

BASH

$ module load r miniconda3 ncbi-blast gaussian
$ module purge
$ module list
No modules loaded

Use module purge to start a fresh shell environment, avoid conflicts when switching projects, or test if your code really needs all those modules.

Callout

Default Modules at Login

When you first log into Sagehen HPC, certain modules might be automatically loaded based on system configuration or your .bashrc file. Use module purge to clear them, then load only what you need for your current task.

Saving Module Collections


Callout

Save Time with Collections

Manually loading the same modules every time gets tedious and error-prone. Module collections let you save a set of modules once and restore them with a single command.

Save your current module configuration as a named collection:

BASH

$ module load openblas/0.3.25 r/4.5.1
$ module save biostats

Lmod stores it in ~/.lmod.d/biostats.

Restoring a collection

BASH

$ module restore biostats
$ module list
Currently Loaded Modules:
  1) openblas/0.3.25    2) r/4.5.1

Listing your collections

BASH

$ module --list-collections
Named collections for /rhome/<myusername>:
  1) biostats
  2) python_analysis
  3) quantum_chem

Setting a Default Collection


Make a collection load automatically when you log in:

BASH

$ module load openblas/0.3.25 r/4.5.1 miniconda3
$ module save default

Now every time you SSH to Sagehen, those modules are loaded automatically. To remove the automatic loading:

BASH

$ module purge
$ module save default

Using Modules in Job Scripts


Callout

Critical for Reproducibility

When you submit a batch job to SLURM, your current module configuration is not automatically passed to the job. Always load modules in your job script.

Example job script

BASH

#!/bin/bash
#SBATCH --job-name=ranalysis
#SBATCH --time=00:30:00
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G

# Load required modules
module load openblas/0.3.25
module load r/4.5.1
module load miniconda3

# Run your analysis
Rscript analysis.R

You can also restore a collection in a job script:

BASH

#!/bin/bash
#SBATCH --job-name=genomics
#SBATCH --time=04:00:00
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G

module restore genomics_pipeline
./run_analysis.sh
Challenge

Challenge 1: Create and Restore a Collection

  1. Load at least three different modules (e.g., openblas, miniconda3, r)
  2. Save them as a collection called “myworkflow”
  3. Purge all modules
  4. Restore the collection
  5. Verify all modules are reloaded

BASH

$ module load openblas miniconda3 r
$ module save myworkflow
$ module purge
$ module restore myworkflow
$ module list

After restore:

Currently Loaded Modules:
  1) openblas/0.3.25    2) miniconda3/py313_26.3.2-2    3) r/4.5.1

The collection saves the exact versions you had loaded and restores them perfectly.

Challenge

Challenge 2: Write a Job Script with Modules

Create a file called test_job.sh with: 1. SLURM header requesting 2 CPUs, 4GB RAM, 10 minutes 2. Load the openblas and miniconda3 modules 3. Print “Modules loaded:” followed by module list 4. Echo “Job completed”

BASH

$ cat > test_job.sh << 'EOF'
#!/bin/bash
#SBATCH --job-name=test_modules
#SBATCH --cpus-per-task=2
#SBATCH --mem=4G
#SBATCH --time=00:10:00

module load openblas miniconda3
echo "Modules loaded:"
module list
echo "Job completed"
EOF

$ chmod +x test_job.sh
$ sbatch test_job.sh

When submitted with sbatch test_job.sh, it creates a job that explicitly loads modules before running commands. Check the output with squeue or look in the log file (slurm-JOBID.out). The job script explicitly loads modules rather than relying on your login environment.

Key Points
  • Load multiple modules with module load module1 module2 module3
  • Use module swap to switch versions cleanly
  • Use module purge to start fresh
  • Save configurations with module save <name> and restore with module restore <name>
  • Set module save default to auto-load modules on login
  • Always load modules in job scripts; don’t rely on your login environment