All in One View

Content from What is High-Performance Computing?

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

Overview

Questions

  • What is high-performance computing (HPC)?
  • What is a cluster and how is it different from my laptop?
  • What is Sagehen HPC?

Objectives

  • Define high-performance computing and understand its role in modern research
  • Distinguish between personal computers and HPC clusters
  • Identify the key components of an HPC cluster

What is High-Performance Computing (HPC)?

High-performance computing refers to using multiple powerful computers (nodes) together to solve computationally intensive problems much faster than a single personal computer could alone. These computers are networked together into what we call a cluster or supercomputer.

Key Advantages of HPC Clusters

  1. Massive Parallelism: Run computations across dozens or hundreds of cores simultaneously
  2. Enormous Memory: Some nodes have 500+ GB RAM (your laptop might have 8-16 GB)
  3. Specialized Hardware: GPUs, high-bandwidth storage, interconnects optimized for communication
  4. Resource Sharing: Fair allocation of resources among hundreds of researchers
  5. Professional Administration: Dedicated IT staff manage hardware, software, security, and backups
  6. Reproducibility: Jobs run the same way every time, independent of what else is running

Introducing Sagehen HPC

Sagehen (sagehen.hpc.pomona.edu) is Pomona College’s research computing cluster. Named after a bird native to California’s Sierra Nevada, Sagehen brings powerful computing resources to Pomona’s research community.

Diagram of the Sagehen HPC cluster. Researchers connect via SSH or the OnDemand web portal to the head node, sagehen.hpc.pomona.edu, which is for login and job submission only. Jobs are dispatched via sbatch or srun to the amd partition of 12 compute nodes with 128 AMD EPYC cores and 500 GB RAM each, or to the gpu partition with 10 GPUs total. A short partition serves quick tests and debugging. All nodes connect over 100 Gb InfiniBand to shared BeeGFS storage: /rhome, /bigdata, and /scratch.
Sagehen HPC’s architecture: researchers connect through the head node, which dispatches jobs to the compute and GPU partitions, all sharing BeeGFS storage over 100 Gb InfiniBand.

Who Should Use Sagehen HPC?

Sagehen is available to:

  • Faculty researchers and their students
  • Graduate students conducting research
  • Undergraduate researchers
  • Course-based computing projects

If you’re doing research that requires significant computation, Sagehen is available to you at no cost.

How HPC Clusters Work

The Job Scheduler: SLURM

SLURM (Simple Linux Utility for Resource Management) coordinates all job execution on Sagehen.

How It Works:

  1. You write a job script describing what you want to run and what resources you need
  2. You submit the job to SLURM using sbatch or srun
  3. SLURM places your job in a queue and monitors resource availability
  4. When resources become available AND your job has high enough priority, SLURM runs it
  5. Your job completes and results are written to output files or your home directory

Why SLURM?

  • Fairness: Ensures every researcher gets a turn using the cluster
  • Efficiency: Runs multiple jobs simultaneously on different nodes
  • Reproducibility: Your job runs the same way every time
  • Accounting: Tracks resource usage for billing and planning
Challenge

Challenge 1: HPC vs. Personal Computer

Which of the following tasks would benefit most from running on an HPC cluster instead of your laptop? Select all that apply.

  1. Writing a research paper in Word
  2. Training a neural network on 500 GB of image data
  3. Browsing the web for literature review
  4. Running a molecular dynamics simulation for 3 weeks
  5. Checking email

B and D would benefit from HPC.

  • A, C, E are everyday tasks that don’t need HPC
  • B involves large data and GPU-accelerated computation, perfect for the gpu partition
  • D is a long-running simulation that would tie up your laptop for weeks
Key Points
  • High-performance computing enables research that would be infeasible on personal computers
  • HPC clusters combine many powerful nodes with fast networks and shared storage
  • Sagehen is Pomona College’s HPC cluster, available at no cost to researchers
  • SLURM is the job scheduler that manages fair resource allocation among all users

Content from Why Use an HPC Cluster?

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

Overview

Questions

  • When do I need HPC for my research?
  • What hardware does Sagehen HPC provide?
  • What are the resource limits on Sagehen?

Objectives

  • Determine when HPC is appropriate for a research workflow
  • Describe Sagehen’s hardware at a high level
  • Understand storage locations and their purposes
  • Know where to get help with HPC at Pomona

When Do You Need HPC?

Your Laptop Might Be Enough If:

  • Your analysis processes small datasets (< 10 GB)
  • Your computations finish in minutes or hours
  • You’re prototyping code or running exploratory analyses
  • You only occasionally need extra computing power

You Need HPC If:

  • Your dataset is very large (100 GB to terabytes)
  • Your computation takes hours, days, or weeks
  • You need to run thousands of analyses or simulations
  • You’re training machine learning models
  • You’re running molecular dynamics, climate models, or other simulations
  • You need specialized hardware like GPUs

Sagehen HPC’s Hardware at a Glance

Compute Nodes (amd partition)

  • 12 AMD EPYC compute nodes
  • Each node: 128 CPU cores, 500 GB RAM, SSD storage
  • Maximum job time: 30 days (720 hours)
  • Best for most research workflows

GPU Nodes (gpu partition)

  • Multiple GPU-accelerated nodes with 10 GPUs in total
  • 4× NVIDIA A100 GPUs (80 GB, high-memory training)
  • 4× NVIDIA L40S GPUs (48 GB, tensor-optimized)
  • 2× NVIDIA RTX PRO 6000 Blackwell GPUs (96 GB)
  • Each node also has 128 CPU cores + 500 GB RAM
  • Maximum job time: 30 days

The Head Node

The head node is your entry point to Sagehen: where you log in, submit jobs, and manage files.

  • Address: sagehen.hpc.pomona.edu
  • CPU: 2 AMD EPYC threads (extremely limited!)
  • RAM: 8 GB per user (shared among all users)
Callout

Critical: Never Run Jobs on the Head Node!

The head node is shared by hundreds of users. If you run computationally intensive work there, you’ll slow down everyone’s ability to submit jobs. SLURM will enforce this; long-running processes on the head node will be terminated.

Always submit jobs to compute nodes using SLURM.

Storage Overview

Sagehen has multiple storage locations, each with different purposes:

Location Quota Backup Persistence Use Case
/rhome/<myusername> ~100 GB Daily Persistent Code, config, small results
/bigdata/lab/<labname> 1 TB/lab Daily Persistent Lab datasets, shared files
/scratch/... None No Temporary (deleted when job completes) Large intermediate files
/tmpfs ~1 GB/job No Temporary (deleted when job ends) Ultra-fast RAM-backed I/O
Callout

Resource Limits per Account

Each user account has limits to ensure fair sharing:

  • Per-account CPU core, GPU, and job queue limits apply
  • Storage quotas: /bigdata shares a single 1 TB lab quota with /rhome (BeeGFS)
  • Contact if you need higher limits for a specific project

Your First HPC Experience on Sagehen HPC

Over the next episodes, you will:

  1. Log into Sagehen via SSH with two-factor authentication
  2. Explore the filesystem and understand where your files go
  3. Learn about partitions and how to choose the right one
  4. Load software using modules to access pre-installed scientific packages
  5. Submit your first job to the SLURM scheduler and see results
Challenge

Challenge 1: Understanding Your Research Needs

Think about a computational project from your own research (or a hypothetical one):

  1. How much data does it involve? (MB, GB, TB?)
  2. How long does it typically take to run? (minutes, hours, days?)
  3. Does it need specialized hardware (GPU)?
  4. Would running this on Sagehen save you time compared to your laptop?

Write down a few sentences about why (or why not) HPC would be useful for this project.

Your answer should discuss:

  • The size of data being processed
  • The computational time required
  • Whether the problem can be parallelized (run in parallel on multiple cores)
  • Availability of specialized hardware needs (GPU, high memory, etc.)

For example: “My machine learning project trains models on 500 GB of image data. On my laptop with 8 cores, this takes 3 weeks. On Sagehen with 128 cores and GPUs, this would probably take 2-3 days, making rapid iteration possible.”

Key Points
  • Use HPC when your data is large, your computation is long, or you need specialized hardware
  • Sagehen has 12 compute nodes (128 cores, 500 GB each) and multiple GPU nodes
  • The head node is for login and job submission only; never run jobs there
  • Different storage locations serve different purposes: home, lab, scratch, tmpfs
  • Contact for help or to request higher resource limits

Content from Connecting to Sagehen HPC

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

Overview

Questions

  • How do I connect to Sagehen using SSH?
  • How do I set up SSH on my operating system?
  • What is the OnDemand web portal?

Objectives

  • Understand SSH (Secure Shell) and its role in remote access
  • Set up SSH access on macOS, Linux, and Windows
  • Know how to use the OnDemand web portal as an alternative
  • Perform your first successful login to Sagehen

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol that lets you securely connect to a remote computer and run commands as if you were sitting at that machine.

Why SSH?

  1. Encryption: All data between your computer and Sagehen is encrypted
  2. Authentication: Confirms you are who you claim to be (via password + DUO)
  3. Remote execution: You can run commands on Sagehen from your local machine
  4. Tunneling: Advanced users can forward network ports for additional security

SSH is the standard protocol for accessing HPC clusters worldwide.

SSH Connection Address 

sagehen.hpc.pomona.edu

Your username is the part before @pomona.edu in your email. If your email is alice@pomona.edu, your username is alice.

Setting Up SSH Access

On macOS and Linux

macOS and Linux include SSH built-in. Open a terminal and connect:

Step 1: Open Terminal - macOS: Applications > Utilities > Terminal (or Cmd+Space, type “Terminal”) - Linux: Ctrl+Alt+T (most distributions)

Step 2: Connect to Sagehen

BASH 

ssh <myusername>@sagehen.hpc.pomona.edu

Step 3: Accept the Host Key

On your first connection, you’ll see a prompt asking you to verify the host. Type yes and press Enter.

On Windows 10/11 with PowerShell

POWERSHELL 

ssh <myusername>@sagehen.hpc.pomona.edu

On Windows with PuTTY

  1. Download PuTTY from https://www.putty.org/
  2. In “Host Name”, enter: sagehen.hpc.pomona.edu
  3. Leave “Port” as 22
  4. Click “Open”
  5. Accept the host key and enter your username

On Windows with WSL

WSL provides a native Linux environment. After installing (wsl --install in PowerShell as Administrator), use the standard SSH command.

Callout

Choosing an SSH Client

  • macOS/Linux users: Use the built-in Terminal application
  • Windows 10+ users: Use PowerShell (simplest) or WSL (most Linux-like)
  • Prefer graphical interface: Use PuTTY
  • Advanced users: Use SSH config files or terminal multiplexers (tmux, screen)

DUO Two-Factor Authentication

When you connect, Sagehen requires DUO authentication at https://duo.pomona.edu.

Flow diagram of connecting to Sagehen. Open Terminal or OnDemand, enter Pomona username, enter password, then the DUO MFA prompt offers three paths: Push approves on the Duo Mobile app, SMS enters a code from a text message, and Passcode enters a backup code. All three paths lead to Connected to Sagehen.
The login flow from opening a terminal to a successful connection, with the three DUO options.

After entering your Pomona password, you’ll see a DUO prompt:

  • Option 1: Push (recommended) – approve the notification on your phone
  • Option 2: SMS – enter the 6-digit code texted to you
  • Option 3: Backup Code – enter a pre-generated backup code
A PowerShell window running ssh to sagehen.hpc.pomona.edu. After the password prompt, a Duo two-factor menu offers Duo Push, a phone call, or SMS passcodes; option 1 is chosen and login succeeds. The commands whoami and hostname then return the username and sagehen.hpc.pomona.edu.
A real login from Windows PowerShell: password prompt, the DUO menu, then verification with whoami and hostname.

If DUO fails, contact Pomona IT Help Desk: (909) 621-8061 or .

The OnDemand Web Portal

If you prefer not to use SSH, access Sagehen through a web browser:

URL: https://ondemand.hpc.pomona.edu/

You’ll sign in with your Pomona credentials (the same Microsoft sign-in page used for other campus services):

Pomona College single sign-on page with a Sign in box prompting for username at pomona.edu, a Next button, and a campus pathway with trees in the background.
The OnDemand sign-in page. Use your full @pomona.edu address here.

After signing in and completing DUO, you’ll land on the OnDemand dashboard:

Pomona College OnDemand dashboard showing pinned apps organized into Clusters with Pomona Cluster Shell Access and System Status, Files with Home Directory, and a row of Interactive Apps, beneath menus for Apps, Files, Jobs, Clusters, and Interactive Apps.
The OnDemand dashboard with pinned apps for shell access, system status, file browsing, and interactive apps.

Advantages of OnDemand

  • No SSH knowledge required
  • Graphical file browser and text editor
  • Interactive desktop sessions (VNC)
  • Jupyter Notebook access
  • Drag-and-drop file transfer

Most advanced users use SSH, but OnDemand is perfect for getting started.

Logging Out

When you’re done, disconnect from Sagehen:

BASH 

exit

Or press Ctrl+D.

Callout

Important Security Notes

  1. Never share your password with anyone, including IT staff
  2. Close your connection when done; don’t leave it running all day
  3. SSH keys: Ed25519 is recommended; RSA-4096 is acceptable
  4. DUO is required: You cannot bypass two-factor authentication
Diagram of the secure authentication stack. Three stacked layers: Strong Password with 14 or more characters per NIST SP 800-63B and length over complexity; DUO MFA two-factor authentication at duo.pomona.edu; and SSH Keys with Ed25519 preferred, RSA-4096 acceptable, and an encrypted passphrase required. The layers converge to Secure Access to the Sagehen HPC cluster.
The three layers that protect your Sagehen HPC account: a strong password, DUO MFA, and SSH keys.
Challenge

Challenge 1: Your First SSH Connection

Connect to Sagehen and verify your environment.

Steps:

  1. Open your terminal (or PuTTY)

  2. Run: ssh <myusername>@sagehen.hpc.pomona.edu

  3. Enter your Pomona password and complete DUO authentication

  4. Verify with:

    BASH 

    whoami
hostname
pwd

You should see your username, sagehen, and /rhome/<myusername>.

If you see [<myusername>@sagehen ~]$ and the verification commands produce correct output, you’re connected.

Common errors:

  • “Permission denied”: verify your username (not email) and password
  • “DUO authentication failed”: ensure Duo Mobile is updated; try SMS
  • “Connection timeout”: check internet; try a different network
Key Points
  • SSH (Secure Shell) is the standard for securely connecting to remote computers
  • macOS and Linux include SSH built-in; Windows users can use PowerShell or PuTTY
  • DUO two-factor authentication is required; push notification is fastest
  • OnDemand (https://ondemand.hpc.pomona.edu/) provides a graphical alternative to SSH
  • Always log out when done with exit or Ctrl+D

Content from Navigating the Filesystem

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

Overview

Questions

  • How is the Sagehen HPC filesystem organized?
  • What are the different storage spaces and what are they for?
  • How do I check my storage quota?

Objectives

  • Understand the different storage locations on Sagehen
  • Distinguish between persistent and temporary storage
  • Check storage quotas and usage
  • Navigate the filesystem using fundamental Linux commands

Sagehen HPC’s Storage Architecture

Sagehen uses a BeeGFS parallel filesystem connected via 100 Gb Infiniband. It has multiple storage systems, each designed for specific purposes.

Diagram of the HPC storage hierarchy with five storage types. /rhome home directory and /bigdata/lab lab shared storage share a 1 TB quota, are backed up, and hold PUBLIC and PROPRIETARY data. gocryptfs encrypted storage on /rhome or /bigdata uses AES-256-GCM encryption and is required for RESTRICTED data. /scratch is fast temporary SSD storage deleted when the job completes. /tmpfs is RAM-backed, fastest, deleted when the job ends, and limited in capacity.
Sagehen HPC’s storage hierarchy: persistent gold tiers at the top, encrypted storage for RESTRICTED data in the middle, and fast temporary tiers at the bottom.

Storage Location Overview

Location Quota Backup Persistence Speed Use Case
/rhome/<myusername> ~100 GB Daily Persistent Medium Code, config, small results
/bigdata/lab/<labname> 1 TB/lab Daily Persistent Medium Lab datasets, shared files
/scratch/... None No Temporary Fast (SSD) Large intermediate files
/tmpfs ~1 GB/job No Temporary Fastest (RAM) Ultra-fast I/O during jobs

Note: /rhome and /bigdata share a combined 1 TB lab quota.

Your Home Directory: /rhome/<myusername>

This is your personal space on Sagehen.

  • Size: Approximately 100 GB
  • Backup: Yes, daily backups
  • When to use: Source code, configuration files, small result files
  • When NOT to use: Large datasets, temporary files from jobs

BASH 

# Navigate to your home directory
cd ~

# See where you are
pwd

# List files with details
ls -lah
Callout

The Tilde Shortcut

In bash, ~ always refers to your home directory:

BASH 

cd ~              # Go to home
cd ~/workshop-0   # Go to workshop-0 in home
cp file.txt ~     # Copy file to home

Lab Storage: /bigdata/lab/<labname>

If you’re part of a research lab, you may have access to shared lab storage.

  • Size: 1 TB per lab group (shared among all lab members)
  • Backup: Yes, daily backups
  • When to use: Large datasets, results shared with collaborators

BASH 

# Check if you have lab storage
ls /bigdata/lab

If you don’t see your lab listed, contact .

Scratch Storage

High-speed temporary SSD storage designed for jobs that need fast I/O.

  • Location: /scratch/$SLURM_JOB_USER/$SLURM_JOB_ID
  • Lifetime: Deleted when job completes (non-persistent)
  • When to use: Large temporary files created during job execution

RAM Disk: /tmpfs

Ultra-fast memory-backed storage.

  • Lifetime: Deleted when job ends
  • Size: Limited (~1-2 GB per job)
  • When to use: Only for jobs with extreme I/O needs

Essential Navigation Commands

BASH 

# Print working directory (where am I?)
pwd

# List files in current directory
ls

# List with human-readable sizes and hidden files
ls -lah

# Change to home directory
cd

# Change to a specific directory
cd /rhome/<myusername>

# Change to previous directory
cd -

# Change up one level
cd ..

Checking Your Storage Usage

Callout

BeeGFS Quota Check

On Sagehen’s BeeGFS filesystem, the standard du command does not work correctly for quota checks. Use the provided script instead:

BASH 

quota_check.sh

This will display your current usage against your quota.

Terminal output of quota_check.sh with two tables. The GROUP Quota table shows a lab group using about 508 GiB of a 931 GiB storage pool with 1.1 million inodes. The User Quota table shows an individual user with a small amount used and no hard per-user limit shown. Both tables include a refresh timestamp.
Output of quota_check.sh: the lab’s shared pool usage on top, your per-user usage below.

If you’re approaching your quota, consider:

  1. Compressing old results: tar czf archive.tar.gz data/
  2. Removing unnecessary files
  3. Moving data to lab storage: mv results /bigdata/lab/<labname>/
  4. Contacting for additional storage
Challenge

Challenge 1: Explore Sagehen HPC’s Storage

Connect to Sagehen and explore the filesystem.

Steps:

  1. Check your home directory: cd ~ && pwd
  2. List its contents: ls -lah
  3. Check for lab storage: ls /bigdata/lab
  4. Run the quota check: quota_check.sh

Questions:

  • What is the full path to your home directory?
  • Do you have access to lab storage?
  • How much of your quota is used?
  • Your home directory should be /rhome/<myusername>
  • Lab storage appears under /bigdata/lab/ if your lab has been set up
  • quota_check.sh shows your current usage vs. your quota limit

If you’re using close to 100 GB, consider cleaning up old files. Contact if you need more space.

Key Points
  • Sagehen uses BeeGFS over 100 Gb Infiniband for its parallel filesystem
  • Your home directory /rhome/<myusername> is persistent and backed up (~100 GB)
  • Lab storage /bigdata/lab/<labname> provides 1 TB shared among lab members
  • Scratch (/scratch) is SSD-based and deleted when your job completes
  • RAM disk (/tmpfs) is the fastest but most ephemeral storage
  • Use quota_check.sh to check your storage usage (not du)
  • Essential navigation: pwd, ls, cd, cd ~, cd ..

Content from Files and Directories

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

Overview

Questions

  • How do I create, copy, move, and delete files?
  • How should I organize my work on Sagehen HPC?
  • What are file permissions and how do I change them?

Objectives

  • Create and manage files and directories on Sagehen
  • Organize research work with a logical directory structure
  • Understand file permissions and access controls
  • Share files securely with collaborators

Creating and Removing Files and Directories

BASH 

# Create a directory
mkdir mydir

# Create nested directories
mkdir -p data/raw/input

# Create an empty file
touch myfile.txt

# Remove an empty directory
rmdir mydir

# Remove a file (be careful!)
rm myfile.txt

# Remove a directory and everything in it (DANGEROUS!)
rm -rf mydir
Callout

Never Use rm -rf Casually!

The command rm -rf directory recursively deletes everything permanently; there is no trash or undo. Always list files first to confirm:

BASH 

# List files FIRST to confirm what you're deleting
ls -la mydir

# Then delete
rm -rf mydir

# Or use interactive mode (walks the tree and asks about every single file before deleting, reply y or n (yes or not))
rm -ri mydir

Interactive deletion in practice: rm -ri asks before removing the directory.{alt=‘A short terminal transcript on Sagehen. mkdir creates a directory named mydir, ls -la shows it is empty, and rm -ri prompts remove directory ’mydir’? before deleting it after the user types y.’}

Working with Files

BASH 

# View file contents
cat myfile.txt

# View beginning of file (first 10 lines)
head myfile.txt

# View end of file (last 10 lines)
tail myfile.txt

# Search for text in a file
grep "pattern" myfile.txt

# Count lines in a file
wc -l myfile.txt

# Search for files by name
find . -name "*.txt"

# Find recently modified files
find . -mtime -7

Organizing Your Work

Create a logical organization in your home directory:

BASH 

cd ~
mkdir -p projects/project1
mkdir -p projects/project2
mkdir -p code
mkdir -p data
mkdir -p results

Example project structure:

/rhome/<myusername>/
├── projects/
│   ├── research-1/
│   │   ├── code/
│   │   ├── data/
│   │   └── results/
│   └── research-2/
├── code/
├── scripts/
└── workshop-0/

File Permissions

Every file and directory has permissions controlling who can read, write, and execute it.

Understanding Permission Output

BASH 

ls -l myfile.txt

Output example:

-rw-r--r-- 1 username groupname 1024 Mar 31 10:30 myfile.txt
  • - = regular file (d = directory)
  • rw- = owner can read and write
  • r-- = group can only read
  • r-- = others can only read

Changing Permissions

BASH 

# Make a file executable
chmod +x script.sh

# Make a file read-only
chmod -w myfile.txt

# Allow group to write
chmod g+w myfile.txt

# Common numeric patterns
chmod 644 myfile.txt  # rw-r--r--
chmod 755 script.sh   # rwxr-xr-x
Terminal transcript in which chmod minus w makes a file read-only, chmod g minus r removes group read, and chmod o minus r removes other read. After each command, ls -l shows the permission string shrinking from r--r--r-- down to owner-only.
Tightening permissions step by step and checking each change with ls -l.
Callout

Sharing Files with Collaborators

To share results with other Pomona researchers:

  1. Put files in /bigdata/lab/<labname> if it’s lab work

  2. Or give them read access to files in your home directory:

    BASH 

    chmod g+rx ~
chmod g+r ~/results/myfile.txt

  3. Share the path with collaborators

Challenge

Challenge 1: Create a Project Structure

Create a directory structure for this workshop and practice file operations.

Steps:

  1. Create directories:

    BASH 

    mkdir -p ~/workshop-0/data
mkdir -p ~/workshop-0/results
mkdir -p ~/workshop-0/scripts

  2. Navigate into the directory: cd ~/workshop-0

  3. Check your location: pwd

  4. Create a test file: echo "Hello Sagehen" > test.txt

  5. View it: cat test.txt

  6. List everything: ls -lah

  7. Return home: cd ~

  8. List recursively: ls -R workshop-0

Questions:

  • What path does pwd show when in workshop-0?
  • How many directories did you create?

pwd should show /rhome/<myusername>/workshop-0.

You created 4 directories total: workshop-0 (main) plus data, results, scripts (subdirectories).

The command ls -R workshop-0 shows the entire tree, including the test.txt file you created.

A terminal transcript creating the data, results, and scripts directories under workshop-0 with mkdir -p, with pwd printing the home workshop-0 path. A test.txt containing Hello Sagehen HPC is created and displayed, ls -lah lists the contents, and ls -R shows the recursive tree.
What Challenge 1 looks like when it works: the workshop-0 tree with its three subdirectories and test file.
Key Points
  • Use mkdir -p to create nested directories in one command
  • Be extremely careful with rm -rf; always list contents first
  • Organize work into logical directories: projects, code, data, results
  • File permissions control read, write, and execute access for owner, group, and others
  • Use chmod to change permissions; share files via /bigdata or by adjusting group permissions

Content from Cluster Architecture

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

Overview

Questions

  • What are partitions and why does Sagehen HPC have three?
  • What hardware is in each partition?
  • How do I view cluster status?

Objectives

  • Understand the concept of partitions in HPC clusters
  • Learn Sagehen’s specific hardware specifications for each partition
  • Use sinfo to query cluster status

What are Partitions?

A partition in SLURM is a logical grouping of compute nodes with shared characteristics. Sagehen uses partitions to organize nodes by hardware type, time limits, and priority.

Think of partitions like different sections of a library: fiction, non-fiction, reference. Each section is organized for its purpose.

Diagram of the Sagehen HPC cluster. Researchers connect via SSH or the OnDemand web portal to the head node, which dispatches jobs via sbatch or srun to the amd partition of 12 compute nodes with 128 AMD EPYC cores and 500 GB RAM each, or the gpu partition with 10 GPUs total. A short partition serves quick tests and debugging with a shorter walltime. All nodes share BeeGFS storage over 100 Gb InfiniBand.
How Sagehen HPC’s partitions fit into the cluster: the head node dispatches jobs to the amd and gpu partitions, with the short partition for quick tests.

The “amd” Partition (Standard Compute)

The primary general-purpose partition for most research.

  • 12 compute nodes
  • Cores per node: 128 (AMD EPYC processors)
  • Memory per node: 500 GB
  • Interconnect: 100 Gb Infiniband
  • Maximum job duration: 720 hours (30 days)

When to use: Most research computations, data processing, simulations, first-time job submissions.

The “gpu” Partition (GPU Acceleration)

For research requiring GPU acceleration.

  • Multiple GPU-equipped nodes
  • CPUs: 128 cores per node, 500 GB RAM
  • GPUs:
GPU Type Count GPU Memory Strength
NVIDIA A100 4 80 GB each Excellent for training
NVIDIA L40S 4 48 GB each Tensor-optimized / inference
NVIDIA RTX PRO 6000 2 96 GB each Largest memory on the cluster (Blackwell)

That’s 10 GPUs in total across the gpu partition.

  • Maximum job duration: 720 hours (30 days)

When to use: CUDA/cuDNN code, deep learning training, GPU-accelerated molecular dynamics.

Callout

GPU Allocation Matters

Request only the GPUs you need:

  • Deep learning: Usually 1-2 GPUs per job
  • Multi-GPU training: 2-4 GPUs (if your code supports it)
  • Standard molecular dynamics: 1 GPU

Each GPU reserved limits availability for others. Be considerate!

The “short” Partition (Quick Jobs and Debugging)

For quick test jobs, debugging job scripts, and rapid prototyping.

  • Shorter maximum walltime than amd and gpu (verify with sinfo -p short)
  • Higher priority for short-duration work
  • Useful for sanity-checking software and submission scripts before running long jobs

When to use: Debugging job scripts, quick test runs, single-task interactive debugging, and any work that finishes within the short partition’s walltime limit.

Viewing Cluster Status with sinfo

BASH 

# See all partitions
sinfo

# More detailed output
sinfo -l

# Show only a specific partition
sinfo -p amd

# Show all nodes and their state
sinfo -N

Example output:

PARTITION  AVAIL  TIMELIMIT   NODES  STATE
amd           up 30-00:00:00     12  alloc
gpu           up 30-00:00:00      4  alloc
short         up    2:00:00      4  idle

(The exact short partition walltime limit may differ — always check sinfo -p short for current values.)

  • AVAIL: Is the partition available (up/down)?
  • TIMELIMIT: Maximum job duration
  • STATE: Current state (alloc=some allocated, idle=free, down=unavailable)
Challenge

Challenge 1: Exploring Sagehen HPC’s Partitions

Query the cluster to understand its configuration.

Steps:

  1. View partition information: sinfo -l
  2. View node details: sinfo -N -l
  3. Check the head node CPU: lscpu | head -20

Questions:

  • How many nodes are in the “amd” partition?
  • What is the maximum walltime for the amd partition?
  • How many cores does a compute node have?
  • amd partition: 12 nodes
  • amd partition maximum walltime: 720 hours (30 days)
  • Each compute node: 128 cores

All standard compute nodes on Sagehen have identical configurations.

Terminal output of two sinfo commands on Sagehen. The partition view lists amd and gpu with a 30-day time limit and short with a 2-hour limit. The node view lists a001 through a012 with 128 CPUs and roughly 512 GB of memory each, plus five gpu nodes, one of which is down.
Real sinfo -l and sinfo -N -l output: the three partitions and per-node cores and memory.
Output of lscpu piped to head, reporting x86_64 architecture, 64 online CPUs from two sockets of 16 cores with two threads per core, vendor AuthenticAMD, and the model name AMD EPYC 7313 16-Core Processor.
lscpu on the head node — note it reports 64 threads on dual AMD EPYC 7313 chips, not the 128 cores of a compute node.
Key Points
  • Partitions group nodes by hardware type and enforce time/resource limits
  • Sagehen has three partitions: amd (general purpose), gpu (GPU-accelerated), and short (quick / test / debug jobs with a shorter walltime)
  • Each compute node has 128 AMD EPYC cores and 500 GB RAM
  • GPU partition offers 10 GPUs: A100, L40S, and RTX PRO 6000
  • Use sinfo to check partition status, node states, and available resources
  • Maximum job time: 720 hours (30 days) on amd and gpu; check sinfo -p short for the short partition limit

Content from Understanding Nodes and Partitions

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

Overview

Questions

  • What are nodes and cores?
  • How does SLURM allocate resources?
  • How do I choose the right partition for my job?
  • What are the resource limits?

Objectives

  • Distinguish between CPU cores, sockets, and nodes
  • Understand how SLURM allocates nodes to jobs
  • Match job requirements to the appropriate partition
  • Know resource limits and how to request increases

Nodes and Cores: The Hierarchy

Understanding the Terminology

  • Node: A complete computer with its own memory, storage, and processors
  • Socket: A physical CPU processor installed in a node
  • Core: An individual processing unit within a socket (128 per node on Sagehen HPC)
  • Thread: A logical processing unit (some CPUs support hyperthreading)
Sagehen (the cluster)
├── amd partition (12 nodes)
│   └── Each: 128 cores, 500 GB RAM
├── gpu partition (multiple nodes)
│   └── Each: 128 cores, 500 GB RAM + NVIDIA GPUs
└── short partition (quick / test / debug jobs)
    └── Shorter walltime limit; check `sinfo -p short`

How SLURM Allocates Resources

When you submit a job, SLURM:

  1. Finds available nodes matching your partition and resource request
  2. Selects the best fit (minimizing wasted resources)
  3. Allocates entire cores to your job (no fractional cores)
  4. Locks the resources until your job completes

Example Allocations

32-core job: SLURM allocates 32 cores on one node; the remaining 96 cores on that node are available for other jobs.

256-core job (2 nodes): SLURM allocates 128 cores on node 1 and 128 cores on node 2. Your job uses both nodes together.

1-GPU job: SLURM allocates 1 GPU plus associated CPU cores on a GPU node.

Callout

The Cost of Wasting Resources

Be as accurate as possible in your resource requests:

  • Job requests 64 cores, uses 32 -> 32 cores wasted per hour
  • Job requests 500 GB RAM, uses 50 GB -> 450 GB wasted
  • Job requests 2 days, finishes in 2 hours -> 46 hours of node time wasted

Over-requesting hurts other users waiting in the queue.

Choosing the Right Partition

Decision Tree

  1. Is your job GPU-accelerated? -> Use the gpu partition
  2. Quick test, debug, or short prototype run? -> Use the short partition (shorter walltime limit, check sinfo -p short)
  3. Everything else (production CPU jobs) -> Use the amd partition
Three-column comparison of Sagehen HPC partitions. The amd default partition has 12 nodes a001 through a012 with 128 AMD EPYC cores and 500 GB RAM per node, a max walltime of 720 hours or 30 days, and is best for long CPU jobs, simulations, data processing, and multi-node MPI. The gpu partition has 10 GPUs: four A100 80 GB, four L40S 48 GB, and two RTX PRO 6000 96 GB, with a max walltime of 720 hours, best for machine learning, CUDA code, and GPU-accelerated computing. The short partition is for quick jobs and debugging with a shorter max walltime; check sinfo -p short.
Side-by-side comparison of the three partitions and what each is best for.

Resource Limits

Resource Limit
CPU cores per job Up to 128 (one full node)
Memory per job Up to 500 GB (node maximum)
GPUs per job Per-account limits apply
Jobs in queue Per-account limits apply
Max job time (amd/gpu) 720 hours (30 days)
Max job time (short) Shorter than amd/gpu — check sinfo -p short
Callout

Exceeding Limits

If you need more resources for a specific project:

  1. Email with your research description, resource needs, and justification
  2. Limits may be temporarily increased for special projects

Examining Hardware Details

BASH 

# See CPU count and details
lscpu

# See memory
free -h

# See GPU devices (on GPU nodes only)
nvidia-smi
Challenge

Challenge 1: Matching Jobs to Partitions

For each scenario, decide which partition is best and explain why:

  1. You’re training a deep learning model that uses CUDA and takes 3 days
  2. You’re debugging a Python script that takes 5 minutes
  3. You’re running a statistical analysis on genetic data (64 cores, 8 hours)
  4. You’re running an MPI simulation requiring 256 cores across multiple nodes

  1. gpu partition – Deep learning needs GPU acceleration. 3 days fits within the 30-day limit.

  2. short partition – Quick debugging (5 minutes) is the canonical use case for the short partition. Use --partition=short with a small --time (e.g., --time=00:10:00).

  3. amd partition – Standard compute job. Doesn’t need GPU. 64 cores fit on one node.

  4. amd partition – Multi-node simulation. 256 cores = 2 nodes (128+128). Doesn’t need GPU.

Key Points
  • Each Sagehen node has 128 cores and 500 GB RAM; SLURM allocates whole cores
  • SLURM finds the best-fit nodes for your resource request automatically
  • Use gpu for GPU-accelerated work, short for quick test / debug jobs (shorter walltime), and amd for general CPU production work
  • Request only the resources you need to avoid wasting shared capacity
  • Contact if you need limits increased for a project

Content from Software Modules Basics

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

Overview

Questions

  • Why can’t I just use any software on Sagehen HPC?
  • What is the module system?
  • How do I find, load, and unload software modules?
  • What if I need software that’s not installed?

Objectives

  • Understand why HPC clusters use module systems
  • Search for available software with module avail
  • Load and unload modules for your work
  • Manage module dependencies and version conflicts
  • Know how to request new software installations

Why Modules? The Problem They Solve

On a personal computer, you install software globally. On a shared cluster with hundreds of researchers, this creates conflicts:

  • Alice needs Python 3.8; Bob needs Python 3.11; Charlie needs Python 2.7
  • Package A needs Library X version 2.0; Package B needs version 3.0
  • Some code compiles best with GCC 9; other code needs GCC 11

A module system allows users to load and unload software dynamically, so multiple versions coexist without conflict.

Lmod: Sagehen HPC’s Module Manager

Sagehen uses Lmod with 90+ pre-installed modules covering programming languages, compilers, scientific libraries, bioinformatics tools, and more.

Viewing Available Modules

BASH 

# List all available modules
module avail

# Search for a specific module
module avail miniconda3

# Show module details without loading
module show miniconda3/py313_26.3.2-2
Terminal output of module avail on Sagehen showing a long multi-column list of software modules under /opt/linux/rocky/8/modulefile, including anaconda3, cuda, matlab, openmpi, r, and three miniconda3 versions with py313_26.3.2-2 marked as the default.
The real module avail listing on Sagehen HPC — miniconda3’s versions are in the middle column, with (D) marking the default.

Loading and Unloading Modules

BASH 

# Load default Python
module load miniconda3

# Load a specific version
module load miniconda3/py313_26.3.2-2

# Load multiple modules at once (check `module avail` for the exact
# names and versions installed on Sagehen)
module load miniconda3/py313_26.3.2-2

# Check what's loaded
module list

# Unload a specific module
module unload miniconda3

# Unload all modules
module purge

What Happens When You Load a Module

Loading a module modifies environment variables (PATH, LD_LIBRARY_PATH, etc.) so the system finds the right software executables and libraries:

BASH 

# Before loading python
echo $PATH
# /usr/local/bin:/usr/bin:/bin:...

module load miniconda3/py313_26.3.2-2

# After loading python
echo $PATH
# /opt/linux/rocky/8/software/miniconda3/py313_26.3.2-2/bin:...

Before and after: loading the miniconda3 module prepends its bin directories to $PATH.{alt=‘A terminal transcript comparing echo PATH before and after module load. After loading miniconda3/py313_26.3.2-2, PATH begins with that module’s bin and condabin directories under /opt/linux/rocky/8/software.’}

Module Families and Conflicts

Some modules belong to the same family. Loading one auto-unloads the other:

BASH 

# Loading a second version of the same package auto-swaps it
module load cuda/11.8.0
module load cuda/12.2.1
# Lmod reports the swap: cuda/11.8.0 => cuda/12.2.1

The same applies to Python versions – only one can be active at a time.

Callout

Good Practice: Start Fresh

Always start your job scripts with no modules loaded:

BASH 

#!/bin/bash
#SBATCH ...

# Always start fresh
module purge
module load miniconda3/py313_26.3.2-2

python my_analysis.py

This ensures reproducible results regardless of what was loaded interactively.

Requesting New Software

If you need software that’s not installed:

  1. Email with software name, version, use case, and documentation link
  2. Include your username and how many people would use it
  3. Expected response: within a few business days

Self-Install Alternative

You can install software in your home directory if needed:

BASH 

mkdir -p ~/software
cd ~/software
# Download, configure, build with --prefix=~/software/
export PATH=~/software/bin:$PATH
Challenge

Challenge 1: Loading and Switching Modules

Practice loading, switching, and purging modules.

Steps:

  1. Load default Python: module load miniconda3

  2. Check the version: python --version

  3. Switch to a different version:

    BASH 

    module unload miniconda3
module load miniconda3/py312_24.9.2-0
python --version

  4. List loaded modules: module list

  5. Purge and reload:

    BASH 

    module purge
module load miniconda3/py313_26.3.2-2
python --version
module list

Questions:

  • Which version loaded by default?
  • What happens after module purge?
  • Can you have two Python versions loaded at once?
  • The default module load miniconda3 loads the most recent stable version
  • module purge removes all loaded modules; module list shows nothing
  • No, loading a second Python version auto-unloads the first (same module family)

This demonstrates Lmod’s ability to manage multiple versions cleanly.

The expected Challenge 1 flow: list, purge, and switch between miniconda3 versions.{alt=‘Terminal transcript of an Lmod session. module list shows miniconda3/py313_26.3.2-2 as the only loaded module; after module purge, module list reports no modules loaded; the user then loads miniconda3/py312_24.9.2-0 and echo PATH shows that version’s bin directory first.’}

Key Points
  • The module system solves software version conflicts on shared HPC clusters
  • Sagehen uses Lmod with 90+ pre-installed packages
  • Use module avail to search, module load to activate, module purge to reset
  • Only one version of each module family can be loaded at a time
  • Always use module purge at the start of job scripts for reproducibility
  • Request new software at

Content from Running Your First Job

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

Overview

Questions

  • What is a batch script?
  • How do I submit a job to Sagehen HPC?
  • How do I monitor my job and retrieve output?

Objectives

  • Understand the difference between interactive and batch jobs
  • Write a simple SLURM batch script
  • Submit jobs with sbatch and monitor with squeue and sacct
  • Retrieve and interpret job output
  • Troubleshoot common job submission issues

Batch Jobs vs. Interactive Jobs

Batch Jobs (Most Common)

Scripts that SLURM runs when resources become available. You submit once and check results later.

  • No need to stay logged in while job runs
  • Reproducible: same script produces same results
  • Can run for days or weeks

Interactive Jobs

Give you a terminal on a compute node for direct command execution.

  • Immediate feedback; great for debugging
  • Must stay connected (job dies if you disconnect)
  • Use for testing and development only

Anatomy of a SLURM Batch Script

The script below is an illustration to read, not to run – we’ll walk through what each line means. You’ll write and submit your own working script in the challenge at the end of this episode.

BASH 

#!/bin/bash
#SBATCH --job-name=hello_hpc
#SBATCH --partition=short
#SBATCH --time=00:10:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=1G
#SBATCH --output=%j_output.log

module purge
module load miniconda3/py313_26.3.2-2

echo "Host: $(hostname)"
echo "Job ID: $SLURM_JOB_ID"
echo "Start time: $(date)"

python -c "print('Hello from Sagehen!')"

echo "End time: $(date)"

This first-job example uses the short partition because it’s a quick test. For production jobs longer than the short walltime limit, use --partition=amd.

Key SBATCH Directives

Directive Purpose Example
--job-name Human-readable name hello_hpc
--partition Which partition amd, gpu, short
--time Maximum runtime HH:MM:SS or D-HH:MM:SS
--ntasks Number of tasks 1 (usually)
--cpus-per-task Cores per task 1 to 128
--mem Memory per job 1G, 100G, 500M
--output Output file (%j = job ID) %j_output.log
--gres GPU request gpu:1, gpu:2

Submitting and Monitoring

Flow diagram of the SLURM job workflow. Write a job script my_job.sh, submit it with sbatch, the job waits in the SLURM queue as PENDING, the scheduler allocates resources, the job runs on a compute node as RUNNING, and when the job finishes it is either COMPLETED with output in slurm-JOBID.out or FAILED, in which case you check the error log.
The life of a batch job, from writing the script to collecting output.

Submit with sbatch

BASH 

sbatch ~/workshop-0/first_job.sh
# Output: Submitted batch job 12345

After submission, SLURM queues the job, allocates resources when available, runs your script, and writes output to the specified file. You can log out while it runs.

Monitor with squeue

BASH 

# Check your current jobs
squeue -u $USER

# Check a specific job
squeue -j 12345

Status codes: R = Running, PD = Pending, CA = Cancelled, CD = Completed.

Check History with sacct

BASH 

# See completed jobs
sacct -u $USER --format=JobID,JobName,State,Elapsed,MaxRSS

Retrieve Output

BASH 

# View your job output
cat ~/workshop-0/12345_output.log

Common Resource Patterns

BASH 

# Quick test (2 minutes, short partition)
#SBATCH --partition=short
#SBATCH --time=00:02:00
#SBATCH --cpus-per-task=1
#SBATCH --mem=500M

# Standard CPU job (8 hours)
#SBATCH --partition=amd
#SBATCH --time=08:00:00
#SBATCH --cpus-per-task=32
#SBATCH --mem=100G

# GPU job (deep learning)
#SBATCH --partition=gpu
#SBATCH --time=72:00:00
#SBATCH --cpus-per-task=16
#SBATCH --mem=100G
#SBATCH --gres=gpu:2

Troubleshooting

Job Won’t Start (Status: PD)

  • Wait longer (resources might be occupied)
  • Reduce resource requests
  • Lower your --time request so the scheduler can back-fill your job sooner
  • Check cluster status: sinfo

Job Terminated Unexpectedly

BASH 

sacct -j 12345
# TIMEOUT = increase --time
# OUT_OF_MEMORY = increase --mem
# FAILED = check output for script errors
Callout

Best Practices for Job Scripts

  1. Always use module purge at the start
  2. Be specific with resource requests (don’t over-request)
  3. Add comments explaining what your job does
  4. Include echo statements so you can see what happened
  5. Test on the short partition before launching long production runs on amd or gpu
Challenge

Challenge 1: Submit Your First Job

Create and submit a batch job that runs a Python computation.

Steps:

  1. Move into your workshop directory (job output lands in the directory you submit from):

    BASH 

    cd ~/workshop-0

  2. Create the Python script:

    BASH 

    cat > ~/workshop-0/fibonacci.py << 'EOF'
def fibonacci(n):
    if n <= 1:
        return n
    a, b = 0, 1
    for _ in range(2, n + 1):
        a, b = b, a + b
    return b

for i in range(1, 21):
    print(f"Fibonacci({i}) = {fibonacci(i)}")
EOF

  3. Create the batch script:

    BASH 

    cat > ~/workshop-0/fib_job.sh << 'EOF'
#!/bin/bash
#SBATCH --job-name=fibonacci
#SBATCH --partition=short
#SBATCH --time=00:05:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=1G
#SBATCH --output=%j_fib.log

module purge
module load miniconda3/py313_26.3.2-2

echo "Running Fibonacci calculation..."
python ~/workshop-0/fibonacci.py
echo "Done!"
EOF

  4. Submit: sbatch fib_job.sh

  5. Monitor: squeue -u $USER

  6. View output: cat ~/workshop-0/*_fib.log

Question: What is Fibonacci(20)?

Fibonacci(20) = 6765

The job should complete in seconds. Check with sacct -j JOBID and view the log file to confirm all Fibonacci numbers were printed.

Terminal transcript of sbatch submitting a batch job, an squeue listing with headers but no rows because the job already completed, and the log file contents listing Fibonacci values 1 through 20, ending with 6765 and Done.
Submitting the job and reading its log — it finishes so fast that squeue is already empty by the time you check.
Key Points
  • Batch jobs are scripts submitted with sbatch; they run when resources are available
  • Every batch script needs #!/bin/bash and SBATCH directives for resources
  • Key directives: –partition, –time, –cpus-per-task, –mem, –output
  • Monitor jobs with squeue -u $USER (running) or sacct (history)
  • Always use module purge in job scripts for reproducibility
  • Test on the short partition before submitting long production jobs to amd or gpu
  • Common failures: TIMEOUT (increase –time), OUT_OF_MEMORY (increase –mem)

Content from Next Steps and Resources

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

Overview

Questions

  • What other workshops are available?
  • Where do I go for help?
  • How do I handle more complex job patterns?

Objectives

  • Know where to find additional HPC training resources
  • Understand common next-step workflows beyond basic job submission
  • Know how to get help from the HPC team

Beyond Your First Job

Now that you can connect, navigate files, load modules, and submit jobs, here are common next steps:

Interactive Jobs for Development

Use srun for interactive sessions on compute nodes:

BASH 

srun --partition=short --time=01:00:00 --cpus-per-task=4 --mem=8G --pty bash

This gives you a bash shell on a compute node where you can test code interactively without running on the head node.

A long terminal transcript. The batch script is shown with cat, an srun command with a ten-minute limit opens an interactive shell and the prompt changes to node a001, sbatch submits the job from there, ls shows the numbered log file, cat prints Fibonacci 1 through 20 ending in 6765 and Done, and exit returns to the head node prompt.
A full edit-test cycle in an interactive session: the prompt changes from sagehen to compute node a001 after srun --pty bash.

Email Notifications

Get notified when your job finishes:

BASH 

#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=username@pomona.edu
A syntax-highlighted batch script in a text editor. The SBATCH header for the fibonacci job on the short partition now includes mail-type END,FAIL and a mail-user line, above the module purge and miniconda3 load lines and the python command.
The Fibonacci batch script with the two mail directives added (students’ addresses are on the mymail.pomona.edu domain).
An email client showing a message from ITS High Performance Computing. The subject reads Slurm Job_id 37651, Name fibonacci, Ended, Run time zero seconds, COMPLETED, Exit Code 0. The message body is empty.
The email SLURM sends when the job ends — the subject line carries the job ID, name, run time, state, and exit code. Note it comes from the its-hpcmbx mailbox; don’t reply to it.

Customizing Your Shell

Edit ~/.bashrc to set up your environment on every login:

BASH 

nano ~/.bashrc

Useful additions:

BASH 

# Helpful aliases
alias ll='ls -lah'
alias sq='squeue -u $USER'
alias sa='sacct -u $USER'

# Set your default editor
export EDITOR=nano

Reload with source ~/.bashrc.

Additional Workshop Topics

The Pomona College HPC Workshop Series covers many advanced topics:

  • SLURM Job Scheduling: Advanced batch scripting, job arrays, dependencies, GPU workflows
  • Data Transfer and Management: Moving data to/from Sagehen HPC with scp, rsync, Globus
  • Security and Access: SSH keys, data classification, encrypted storage
  • OnDemand Portal: Graphical access, Jupyter, RStudio on the cluster
  • Domain-Specific Workshops: R, Python, bioinformatics, and more

Getting Help

HPC Support

  • Email:
  • Include in your email:
    • Your username
    • Job ID (if applicable)
    • Error messages or output
    • What you expected vs. what happened

Common Self-Help Commands

BASH 

# Check cluster status
sinfo

# Check your running/pending jobs
squeue -u $USER

# Check completed job details
sacct -j JOBID --format=JobID,JobName,State,Elapsed,MaxRSS

# Check your storage quota
quota_check.sh

# See what modules are loaded
module list
Callout

Quick Reference Card

Task Command
Connect ssh <myusername>@sagehen.hpc.pomona.edu
Submit job sbatch script.sh
Check jobs squeue -u $USER
Job history sacct -u $USER
Cancel job scancel JOBID
Cluster status sinfo
Load software module load package
Reset modules module purge
Check quota quota_check.sh
OnDemand https://ondemand.hpc.pomona.edu
Challenge

Challenge 1: Plan Your First Real Project

Think about a research computation you want to run on Sagehen. Write down a plan covering:

  1. What software/modules do you need?
  2. How much memory and how many cores?
  3. How long will it take?
  4. Which partition should you use?
  5. What input data do you need to upload?
  6. Where should output be saved?

Draft a skeleton batch script for this project (just the SBATCH headers and module loads; the actual command can be a placeholder).

A good plan should include:

BASH 

#!/bin/bash
#SBATCH --job-name=my_research
#SBATCH --partition=amd          # or `gpu` for GPU jobs, `short` for quick tests
#SBATCH --time=08:00:00          # realistic estimate
#SBATCH --cpus-per-task=16       # based on your code's parallelism
#SBATCH --mem=64G                # based on data size
#SBATCH --output=%j_output.log

module purge
module load miniconda3/py313_26.3.2-2   # or whatever you need (check module avail)

# Your research command here
python my_analysis.py --input /bigdata/lab/<labname>/data --output ~/results/

Key considerations: - Start with a short test on the short partition (small --time, e.g., 10–30 minutes) before launching production work on amd or gpu - Scale up resources once you know what your code needs - Save important output to /rhome or /bigdata, not /scratch

Key Points
  • Use srun --pty bash for interactive compute sessions instead of running on the head node
  • Email notifications keep you informed about job completion and failures
  • Customize ~/.bashrc for a more productive login environment
  • Additional workshops cover SLURM advanced features, data transfer, security, and more
  • Contact for help; include your username, job ID, and error messages
  • Use quota_check.sh (not du) to check BeeGFS storage usage