Getting Started — StudentHPC Portal

Before you begin

You need an approved allocation. If you have not applied yet, start with the allocation request form — nothing below will work until a reviewer has issued your account.

Connecting over SSH #

Sagittarius is reached through a login node. Login nodes are for editing, compiling, submitting, and moving data — not for running your science. Anything heavy belongs in a batch job.

bash

# Replace jsmith with the username issued in your approval email
$ ssh [email protected]

First-time connections prompt you to verify the host key fingerprint. Compare it against the fingerprint in your approval email before typing yes; if they differ, stop and contact support.

Using an SSH key

Password logins are rate-limited. Generate a key pair on your own machine and install the public half on the cluster:

bash

# On your laptop -- ed25519 keys are smaller and faster than RSA
$ ssh-keygen -t ed25519 -C "[email protected]"
$ ssh-copy-id [email protected]

Never share a private key

Your private key (~/.ssh/id_ed25519) never leaves your machine, and never gets copied to the cluster. Sharing an account is grounds for revoking an allocation — if a labmate needs access, they apply for their own.

Software modules #

Software is provided through environment modules rather than installed system-wide, so incompatible toolchains can coexist. Load what you need at the top of every job script — module state does not survive from your shell into a batch job.

bash

$ module avail                    # everything installed
$ module spider gromacs           # find versions + prerequisites
$ module load gromacs/2023.3      # always pin the version
$ module list                     # what is loaded right now
$ module purge                    # reset to a clean environment

Pin your versions

module load gromacs resolves to whatever is default today, which may not be what is default in six months. Writing gromacs/2023.3 means the run that produced your figures can be reproduced when a reviewer asks.

Your first job #

A Slurm job script is an ordinary shell script with #SBATCH directives at the top. Save this as hello.sh in your scratch directory:

~/scratch/hello.sh

#!/bin/bash
#SBATCH --job-name=hello
#SBATCH --partition=debug
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --time=00:05:00
#SBATCH --output=hello-%j.out

echo "Running on $(hostname)"
echo "Job ID: $SLURM_JOB_ID"
echo "Allocated CPUs: $SLURM_CPUS_ON_NODE"

Submit it, watch it, and read the output:

bash

$ sbatch hello.sh
Submitted batch job 184203
$ squeue --me
   JOBID PARTITION  NAME    USER ST  TIME NODES NODELIST
  184203     debug hello  jsmith  R  0:03     1 scg-c0042
$ cat hello-184203.out
Running on scg-c0042
Job ID: 184203
Allocated CPUs: 48

That is the whole loop: write a script, sbatch it, check squeue, read the output file. Everything else is detail — and the detail lives in Slurm job scripts.

Where your files live #

Quotas and purge policy are placeholders — confirm before publishing.
Path	Purpose	Quota	Backed up	Purged
`/home/$USER`	Scripts, source, small configs	50 GB	Snapshots	Never
`/scratch/$USER`	Job I/O and intermediate data	5 TB	No	60 days idle
`/projects/$GROUP`	Shared group datasets	By allocation	Snapshots	Never

Scratch is not backed up

/scratch is fast because it is not protected. Files untouched for 60 days are removed automatically and cannot be recovered. Move anything you intend to keep into /home or off the cluster entirely when the run finishes.