| name | hpc-spack |
| description | Build, review, debug, and stabilize Spack-based HPC software stacks. Use when working with Spack specs, variants, compilers, externals, environments, concretization, compiler or MPI matrices, site stacks, binary reuse, or Spack install and reuse failures. |
HPC Spack
Treat Spack as a stack manager, not just an install command. Decide the compiler, MPI, externals, concretization policy, and environment boundary before changing package-level variants.
Start
- Read
references/spec-and-variant-matrix.md before writing or repairing a Spack spec.
- Read
references/compilers-and-external-packages.md when compiler registration, packages.yaml, or external software ownership is in scope.
- Read
references/environments-and-concretization.md when using spack.yaml, lockfiles, unified concretization, or multi-package environments.
- Read
references/compiler-and-mpi-matrix.md when the stack depends on compiler or MPI families and their combinations.
- Read
references/modules-buildcaches-and-binary-reuse.md when integrating site modules, buildcaches, mirrors, or binary reuse.
- Read
references/site-stack-and-reproducibility.md when the goal is a durable site stack, reproducible environment, or cluster handoff.
- Read
references/error-recovery.md when concretization, install, compiler detection, external-package, or reuse behavior fails.
Work sequence
- Decide the stack boundary first:
- site-provided externals
- project-local Spack environment
- site-maintained Spack stack
- Register compilers and externals before solving the dependency graph.
- Write the minimal spec or environment that captures the intended compiler and MPI choices.
- Concretize and inspect the solved graph before launching a long install.
- Capture environment manifests, overrides, and reuse settings with the build record.
Guardrails
- Do not mix ad hoc package installs and environment-managed installs casually.
- Do not force many variants at once before the compiler and external package model is coherent.
- Do not treat concretization policy as an afterthought when several packages must coexist.
- Do not hide site-provided MPI, CUDA, or math libraries from Spack if the cluster expects them to be reused as externals.
Additional References
Load these on demand:
references/spec-and-variant-matrix.md for spec syntax and variant selection patterns
references/compilers-and-external-packages.md for compiler registration and external package ownership
references/environments-and-concretization.md for spack.yaml, lockfiles, and concretization behavior
references/compiler-and-mpi-matrix.md for compiler/MPI cross-product planning
references/modules-buildcaches-and-binary-reuse.md for binary reuse and module integration
references/site-stack-and-reproducibility.md for site-stack hygiene and durable reproducibility
references/error-pattern-dictionary.md for fast matching of common Spack failure classes
Reusable Templates
Use assets/templates/ when a concrete starting point is faster than rebuilding the Spack workflow from scratch, especially:
spack-env-minimal.yaml
packages-external-example.yaml
compilers-example.yaml
spack-create-env-and-install.sh
spack-build-smoke-slurm.sh
Outputs
Summarize:
- chosen environment boundary
- compiler and MPI strategy
- external package assumptions
- concretization or binary-reuse choices
- the exact Spack failure class if the workflow is being repaired