Can I run this?
Confirm these assumptions before execution:
- Allocation: you have authorized Slurm access, an account, and permission to request the needed CPU, memory, and wall time.
- Security and network: the coordinator can use loopback within one node; no root access, privileged daemon, or inbound public port is required.
- Storage: a center-approved job-scoped path has enough quota for the image, cache, runtime state, and outputs.
- Runtime and image: Apptainer is available on compute nodes, and you have an approved image path and digest.
- Readiness: a bounded semantic probe can reach the coordinator before any worker starts.
Check the prerequisites
- Run
command -v sbatchand confirm your center’s account and partition syntax. If either fails, use PREREQ-SLURM. - Run
command -v apptainerandapptainer --versionin the compute-node module environment. If either fails, use PREREQ-APPTAINER. - Create and remove a private test file through the intended container bind. If that fails, use STORAGE-UNAVAILABLE.
Record your local values
Write down the account or project, partition or queue, wall time, CPU and memory, runtime module, image path and digest, scratch root, worker and task bounds, readiness timeout, and any approved tunnel or accelerator request.
Run
- Open the release-pinned sbatch workflow or review the annotated implementation reference in Module 2.
- Apply the local values without exceeding the documented worker, task, or timeout bounds.
- Submit the baseline script once.
- Confirm the readiness gate passes before workers start. If it expires, use READINESS-TIMEOUT.
Verify
Accept success only when the scheduler state, exit status, result file, expected item count, uniqueness, and verifier output agree. Module 2 states the complete result-based completion check.
If execution still fails
Use the diagnostic registry to match the visible symptom. If no entry matches, report a workflow defect with sanitized commands, expected behavior, and observed behavior.