Cluster Run Guide (Slurm)

Table of Contents

• 2. Core Command Patterns
• 4. Submission Flow

This guide documents how pic.flow converts case configs into scheduler artifacts for cluster execution.

1. Required Input Roles

Typical cluster-enabled run uses:

• case.yml
• solver.yml
• monitor.yml
• post.yml
• cluster.yml (scheduler contract)

Initialize templates from examples, then customize per cluster/account policy.

2. Core Command Patterns

Generate and submit:

./scripts/pic.flow run \
  --case <case.yml> \
  --solver <solver.yml> \
  --monitor <monitor.yml> \
  --post <post.yml> \
  --cluster <cluster.yml> \
  --scheduler slurm

Generate only (no submission):

./scripts/pic.flow run ... --scheduler slurm --no-submit

6. Inspect Generated Artifacts

In run directory, scheduler generation typically produces:

• solver.sbatch
• post.sbatch
• manifest.json
• submission.json (when submitted)

These coexist with standard runtime control artifacts used by solver/postprocessor binaries.

4. Submission Flow

1. YAML validation and contract checks,
2. run directory + control artifact generation,
3. sbatch script rendering from scheduler settings,
4. optional solver submission,
5. optional post job with dependency linkage.

This allows consistent local dry-run and cluster production flow from the same inputs.

5. Practical Notes

• Prefer --no-submit first when validating new scheduler settings.
• Keep cluster defaults in reusable templates (examples/master_template/master_cluster.yml).
• If queue policies differ by partition/account, encode them in cluster.yml instead of editing generated scripts manually.

See also:

• Sweep and Study Guide
• The Conductor Script: pic.flow
• Common Fatal Errors and Fixes