Installing software with Spack¶

HPC software can have multiple dependencies and be quite challenging to install. While Conda is a popular tool for general-purpose software, HPC software often runs close to the hardware and builds directly on several layers of libraries and drivers that need to work optimally together. In particular if your application uses MPI and/or CUDA, it is worth checking if it can be installed via Spack (the Supercomputer PACKage manager). This has the distinctive advantage over conda that Spack will allow you to build your custom packages and modules on top of (and thus fully compatible with) the DelftBlue software stack.

This is only a brief walkthrough specific to DelftBlue. For extensive documentation and tutorials, see the Spack documentation.

Selecting Your Target Stack (CPU or GPU)¶

Starting with the 2026 software stack, you must explicitly choose which environment stack you are building for by loading either the CPU or GPU module:

• CPU Stack: module load 2026 cpu
• GPU Stack: module load 2026 gpu

Make sure you load the stack matching the architecture you plan to target. The instructions below reference the cpu stack as the primary example, but for GPU-accelerated software, replace cpu with gpu in all path references.

Where should I install software?¶

By default, software will be installed in a location within the Spack directory that you get after cloning the Spack repository (see below).

It is recommended to install software packages in your /home folder. If the size of the installation is very large, you may instead use /scratch temporarily (note that files get cleaned up after 6 months unless you update their access timestamp).

If you want to install software to be used by multiple people (e.g., a course or a research group), please request a project folder for this purpose.

Clone the Spack repository and activate Spack¶

To ensure maximum binary compatibility with pre-built stack components, your local Spack instance must match the exact commit version used to build DelftBlue's central 2026 stack.

1. Load Python and target the desired stack:

   module load 2026 python
   module load 2026 cpu  # Use 'module load 2026 gpu' if building for GPU nodes
   

2. Extract the exact Spack commit version from the lockfile: Run this one-liner to pull the matching commit SHA from the stack's lockfile:

   SPACK_COMMIT=$(jq -r '.spack.commit // empty' /apps/2026/cpu/environment/spack.lock)
   

   (Note: For the GPU stack, replace /cpu/ with /gpu/ in the path above).

3. Clone Spack into your $HOME and checkout the matching version:

   git clone https://github.com/spack/spack.git ${HOME}/spack
   cd ${HOME}/spack
   git checkout ${SPACK_COMMIT}
   

4. Activate Spack in your shell:

   source ${HOME}/spack/share/spack/setup-env.sh
   

   You may want to put this line into your ${HOME}/.bashrc file or a dedicated setup script so that you always have access to Spack. After sourcing, the spack command will be available and $SPACK_ROOT points to its base directory.

Copy required configuration files¶

We want to build additional software "on top" of the existing software stacks on DelftBlue in order to avoid multiple installations of system packages and to ensure consistent module creation.

cp /projects/unsupported/spack2026-cpu/etc/spack/*.yaml $SPACK_ROOT/etc/spack/

(For the gpu stack, simply replace cpu by gpu).

(This configuration prevents Spack from rebuilding system-level libraries like SLURM and RDMA-core, linking directly against DelftBlue's pre-built stack instead).

Find compilers and check dependencies¶

It is advisable to make some recent compilers available to spack, in particular those that were used to build the stack. For example:

spack find gcc
spack load gcc@13.4.0
spack compiler find

You can now check if important upstream dependencies (like MPI) are detected correctly:

spack find -v -l openmpi

Finding and configuring your software¶

As an example, let's try to install the Finite Element package FEniCS. To list related packages:

spack list fenics

spack info fenics-dolfinx

spack spec -I --reuse fenics-dolfinx ^slepc

• The -I flag shows which packages are already available and which need to be installed.
• The --reuse flag instructs Spack to reuse pre-installed upstream packages as much as possible.
• Packages marked with [^] or [e] indicate dependencies satisfied directly by DelftBlue's upstream software stack.

Installing the software¶

Once the spack spec output is verified, trigger the build process:

spack install -j 8 --reuse fenics-dolfinx ^slepc

Spack will compile only your requested package and any non-existing dependencies into your home/scratch directory while linking against the 2026 central stack.

Using the installed software module¶

To integrate your custom-installed software into your module environment, extend your module search path to include your local Spack Lmod directories:

# Locate your generated Core module directory
find $SPACK_ROOT/share/spack/lmod -name "Core"

Add the discovered path(s) to your environment using module use:

module use /home/<netid>/spack/share/spack/lmod/linux-rhel8-x86_64/Core

You can append these module use lines into your ${HOME}/.bashrc file to ensure your custom modules are automatically discovered upon login.

Important Notes & Troubleshooting¶

Concretization phase¶

If spack spec -I --reuse does not pick a desired installed version of a dependency, locate the hash of the upstream dependency using spack find -v -l <dependency> and explicitly pass it to the concretizer:

spack spec -I --reuse <package> ^<dependency>/<hash>

Generated module files are broken¶

If you find problems with the module files generated by spack, or if it did not generate a module file while the software was correctly installed, use:

spack module lmod refresh --delete-tree -y

If the module file you are trying to load exists but lmod doesn't find it, it can be a caching iscue. Simple solution:

rm -rf ~/.cache/lmod/*

Disk Space & Quota¶

If your build fails due to disk quota limits, switch your build directory temporarily to /scratch or change to your project group context using newgrp <project-name> prior to installation.

Multiple spack instances¶

If you have used spack before (e.g. with an older software stack as upstream), setting up a new instance may result in conflicts because spack tends to copy configuration files to ~/.spack/. For a fresh start it is recommended to remove ~/.spack/ completely.