Glossary and sources
Looking up an unfamiliar term? Start with the Glossary. Checking a command or policy? Use the primary links below, and please flag anything that has drifted.
Recommended background: earlier CSG sessions
These earlier CSG training sessions are a useful refresher before this playbook. Together they cover CPU, RAM, disk, profiling tools such as htop, /usr/bin/time, and pidstat, disk I/O, shared-system etiquette, and introductory SLURM concepts.
| Session | Slides | Video |
|---|---|---|
| Profiling your programs & running them on the cluster, Part 1 — Ryan Welch and Daniel Taliun (2018) | Open slides | Watch video |
| Profiling your programs & running them on the cluster, Part 2 — Ryan Welch and Daniel Taliun (2018) | Open slides | Watch video |
Use these sessions for durable concepts, not current hardware, login-node, storage, or policy details. For today’s Great Lakes and Armis2 rules, use the dated U-M reference below.
Current lab materials
- SLURM: From a Single Job to Efficient Parallel Computing — a 23-page teaching deck covering lifecycle, mental models, robust jobs, resource tuning, arrays, dependencies, recovery, troubleshooting, and workflow abstractions.
- SLURM Session Cheatsheets — printable command, tuning, troubleshooting, and U-M operational cards.
- Standalone example pipeline ZIP — the runnable contents of the repository’s
examples/directory under aslurm-example-pipeline/top-level folder.
The web guide and tested repository files are the versions we keep current. The PDFs are handy for teaching, but use the dated U-M Cluster Reference instead of a downloaded card when policy matters.
U-M operations and policy
Time-sensitive operational statements are centralized in the U-M Cluster Reference. These primary pages were last checked for this playbook on September 2, 2026:
- U-M ARC SLURM User Guide
- Great Lakes defaults, partition limits, and storage
- Great Lakes policies and billing
- Armis2 defaults, partition limits, and storage
- Armis2 policies
- Armis2 user guide and sensitive-data scope
SLURM behavior
- Job arrays
sbatchand dependenciessqueueand job reason codessacctsstatscontrolscancel- CPU and memory request semantics
- Quick-start command roles
- Environment behavior FAQ
seffcontribution source
Workflow layers
These are options to consider when raw arrays stop being the clearest interface. Choose a tool because it removes a recurring problem, not simply because it adds another layer.
| Tool | Useful when… | Primary documentation |
|---|---|---|
batchtools / future.batchtools | an existing R parallel workflow needs a scheduler backend | batchtools · future.batchtools |
BiocParallel | Bioconductor code should dispatch through a BatchtoolsParam | BatchtoolsParam vignette |
targets + crew.cluster | an R dependency graph needs distributed workers and incremental rebuilds | targets with crew · crew_options_slurm() |
clustermq | R function calls need a concise cluster-backed map interface | clustermq user guide |
submitit | Python functions should run through one local-or-SLURM interface | submitit project |
| Nextflow | a multi-stage file pipeline needs resume, reports, containers, or per-process resources | Executors · Processes · Reports · Cache and resume · Configuration |
| Snakemake | rule-based file dependencies need incremental execution and a cluster executor | Executor overview |
How we choose what to trust
- Scheduler syntax and behavior should be supported by current SchedMD documentation or a reproducible test.
- U-M operational facts should be dated, linked to official ARC documentation, and kept in the cluster reference rather than repeated across topic pages.
- Resource recommendations should come from representative accounting evidence, not an unexplained fixed value.
- The six operating principles remain stable: prove locally, match resources to behavior, use stable manifests, throttle arrays, aggregate after success, and recover failed elements.
AI assistance and validation
This playbook was developed with substantial generative AI assistance. The commands and examples—including those covered by repository tests—are starting points, not guarantees that they will work unchanged in your environment. Cluster configurations, software environments, and policies change. Always begin with a small, non-sensitive test, inspect the logs and results, and confirm current requirements in the official U-M ARC and SchedMD documentation before scaling up.
If a source has changed or a link is broken, open an issue and include the affected page plus the current official source.