Getting Started
A guide for new members of the group. Under construction — more detail coming soon.
Basics
Before touching a cluster, set up a comfortable local environment. You will spend most of your time in a terminal and an editor, so it is worth getting these right on day one.
Terminal
On macOS, install iTerm2 — a far more capable replacement for the built-in Terminal (split panes, search, better copy/paste). If you use Homebrew (recommended for managing software on macOS):
brew install --cask iterm2
On Windows, use WSL with Windows Terminal so you have a real Linux environment.
Editor
Install VS Code
and add the Remote — SSH extension. This lets you edit
files living on OSCER or lxplus directly from your laptop, with
full syntax highlighting and search — much nicer than editing
over a terminal editor for large projects. (That said, learn enough
vim to make quick edits on any machine.)
Git
All of our code lives in git repositories on GitHub and CERN GitLab. Configure your identity once per machine:
git config --global user.name "Your Name"
git config --global user.email "you@ou.edu"
Generate an SSH key (ssh-keygen -t ed25519) and add
the public key (~/.ssh/id_ed25519.pub) to both GitHub
and CERN GitLab so you can push without typing passwords.
Learning resources
The HSF Training Center has excellent self-paced material on the shell, git, Python, and the rest of the HEP software toolkit. If you are new to any of these, start there.
OSCER account
Our group computes on OSCER, the OU Supercomputing Center for Education & Research. Steps to get an account:
- Complete the New Account Request Form.
- If approved, you will receive an email when your account is created.
- Log in with your initial password and change it IMMEDIATELY if prompted (or manually if not prompted).
The OSCER documentation is the reference for anything not covered on this page. For account problems, quota issues, or anything else cluster-related, contact support@oscer.ou.edu (see the OSCER support page).
Logging in
Once your account is active, connect with:
ssh -XY [username]@sooner.oscer.ou.edu
To save typing, add an entry to ~/.ssh/config on your
laptop:
Host sooner
HostName sooner.oscer.ou.edu
User [username]
ForwardX11 yes
ForwardX11Trusted yes
after which ssh sooner is all you need.
Requesting a node on Sooner
The group has a dedicated Slurm partition, currently named
ouheptmp (this will change to ouhep in
the future).
Never run real work on the login nodes — they are
shared by everyone and only meant for editing files and submitting
jobs. Always run your code on an interactive node. To request one:
srun -p sooner_test --container=el9hw --pty $SHELL
This drops you into a shell on a compute node inside an EL9 container, which is what ATLAS software expects.
GPU access
For GPU work (e.g. machine learning training), request a GPU node with:
srun -p ouheptmp --container=el9hw --gres=gpu:1 --ntasks=1 --cpus-per-task=16 --mem=40G --pty $SHELL
Check what you were allocated with nvidia-smi once
the shell opens.
Submitting batch jobs
For anything longer than a quick test, submit a batch job instead of holding an interactive shell. Write a submission script like:
#!/bin/bash
#SBATCH --partition=ouheptmp
#SBATCH --container=el9hw
#SBATCH --job-name=myjob
#SBATCH --output=logs/%x-%j.out
#SBATCH --time=12:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
setupATLAS
asetup Athena,main,latest
# your commands here
and submit it with:
sbatch myjob.sh
Useful commands for managing your jobs:
squeue -u $USER # list your queued and running jobs
scancel [jobid] # kill a job
sacct -j [jobid] # accounting info for a finished job
%x and %j in the output path expand to
the job name and job ID. Make sure the logs/
directory exists before submitting. Request only the resources you
need — smaller jobs schedule faster.
Storage: OURDisk
The group's OURDisk partition lives at:
/ourdisk/hpc/ouhep/
We have a shared quota of 93 TB. Please be mindful not to fill it up — clean up datasets you no longer need, and check with the group before copying in anything large.
Setting up Athena
ATLAS software is distributed via CVMFS, which is mounted on the
OSCER nodes. First, add this to your ~/.bashrc:
export ATLAS_LOCAL_ROOT_BASE=/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase
alias setupATLAS='source $ATLAS_LOCAL_ROOT_BASE/user/atlasLocalSetup.sh'
Then, on an interactive node (see above), initialize the ATLAS environment and set up an Athena release:
setupATLAS
asetup Athena,main,latest
Use Athena,main,latest for development against the
main branch. For analysis, you will usually pin a specific release
(e.g. asetup Athena,25.0.25) so results are
reproducible.
Working with the Athena repository
Athena development uses a sparse checkout: you check out only the packages you are changing, and build them against the release. First fork the athena repository on CERN GitLab (once), then:
lsetup git
git atlas init-workdir ssh://git@gitlab.cern.ch:7999/[username]/athena.git
cd athena
git atlas addpkg MyPackage
git checkout -b main-my-topic upstream/main --no-track
where MyPackage is the package you want to modify
(add as many as you need with further git atlas addpkg
calls). Build the checked-out packages in a separate build
directory:
mkdir ../build && cd ../build
cmake ../athena/Projects/WorkDir
make -j8
source x86_64-*/setup.sh
After sourcing the setup script, your locally built packages
shadow the ones in the release. When your changes are ready,
push your branch to your fork and open a merge request to
atlas/athena.
For a full walkthrough, see the ATLAS software tutorial and the ATLAS git workflow tutorial.
Python environments with mamba
Manage Python with mamba, a fast drop-in replacement for conda. On OSCER, mamba is already available as a module — do not install your own. Load it with:
module load Mamba
(The first time, run mamba init bash and log out and
back in so environment activation works.) Then create one
environment per project — never install packages into the
base environment:
mamba create -n myanalysis python=3.12
mamba activate myanalysis
Environments keep each project's dependencies isolated and reproducible. Note that environments can get large — if your home area fills up, contact OSCER support.
Machine learning on OSCER
For machine learning work, create a dedicated environment and install PyTorch and Lightning into it (the PyTorch wheels bundle CUDA, so the same install works on CPU and GPU nodes):
mamba create -n ml python=3.12
mamba activate ml
pip install torch lightning
Then request a GPU node (see the OSCER tab) and check that the GPU is visible:
python -c "import torch; print(torch.cuda.is_available())"
Do the installation itself from an interactive node rather than a
login node — the downloads are large. Add whatever else your
project needs (numpy, matplotlib,
jupyterlab, …) to the same environment.
HEP data analysis: the Scikit-HEP stack
For ntuple-level analysis we recommend the Scikit-HEP ecosystem: modern, columnar Python analysis that plays well with the broader scientific Python world (NumPy, matplotlib, machine learning frameworks) — no compiled ROOT macros required. The core pieces:
uproot— reads and writes ROOT files directly into arrays, with no ROOT installation neededawkward— NumPy-style operations on jagged arrays (variable-length collections like jets per event)hist— histograms with a clean API for filling, slicing, and projectingmplhep— matplotlib styles and helpers for publication-quality HEP plots (including the ATLAS style)vector— Lorentz vectors and kinematics on arrays
Install them into your environment from conda-forge:
mamba install uproot awkward hist mplhep vector jupyterlab
A minimal analysis looks like:
import uproot
import awkward as ak
import hist
import mplhep as hep
import matplotlib.pyplot as plt
tree = uproot.open("ntuple.root")["tree"]
jet_pt = tree["jet_pt"].array() / 1000.0 # MeV to GeV
h = hist.Hist.new.Reg(50, 0, 500, label="Jet $p_{T}$ [GeV]").Double()
h.fill(ak.flatten(jet_pt))
hep.style.use(hep.style.ATLAS)
h.plot()
plt.savefig("jet_pt.pdf")
The HSF Scikit-HEP training module is a good hands-on introduction to the whole stack.