Spack

Getting started

The official spack documentation can be found at https://spack.readthedocs.io/en/v0.21.1

In order to use Spack, you need to load the corresponding module first. The module name for each software stack that has a Spack module is listed below:

Software StackModule Name
SCC Modules (scc-lmod)spack-user
NHR Modules (nhr-lmod)spack
Note

The HLRN Modules (hlrn-tmod) software stack doesn’t provide a Spack module.

Then, load it by

load spack module:
module load spack-user
module load spack

Please note: Some commands of Spack require extra shell functionality and you need to source the environment script. This will also be shown after you load the spack module:

source $SPACK_ROOT/share/spack/setup-env.sh

Now Spack is ready and you can use spack load command to load necessary software or spack install SPEC to install the software.

Loading software

You can find spack packages that are already installed using spack find:

spack find py-numpy

You need to pick a specific version of those listed to load:

spack load py-numpy target=sapphirerapids

Installing software

In most cases, it is enough to know the package name to install the software. For instance, if you want to install zlib, then you can simply run the following command:

spack install zlib

In general, you need to provide a specification and dependencies for the command spack install, where you can select versions, compiler, dependencies and variants. To learn more about Spack specification, please visit Spack’s documentation.

Hardware Architectures

Since we have multiple CPU architectures, connection fabrics, and GPU architectures on the clusters; it can pay off to optimize your software for the architecture of the nodes it will run on. For example, if you plan on running your software on a Cascadelake node, it can be accelerated by compiling it to use Cascadelake’s AVX512 instructions. A package would be compiled by setting the target in the spec to the desired CPU architecture like:

spack install gromacs target=cascadelake

The spack arch command will print the full CPU and OS architecture/target of the node you are on (e.g. linux-rocky8-sapphirerapids), and spack find will show you what you have built for each architecture (architecture is in the headers). The architecture/target is composed of the operating system (linux), the Linux distribution, and the CPU architecture. Note that the architecture/target does not capture other important hardware features like the fabric (mainly MPI libraries and their dependencies) and CUDA architecture. For CUDA, the cuda_arch parameter should be set to the CUDA compute capability.

Make sure to install the software separately for every architecture you want it to run on from a node with that particular architecture. The easiest way to ensure you are on the right architecture is to start an interactive slurm job on the same partition (and same kind of node if a partition is mixed architecture) you want to use the software on. To learn more about Spack and how to install software you can go through its tutorial at https://spack-tutorial.readthedocs.io/en/latest/

Tip

Software installed as modules is already built for all targets separately. The correct version is chosen automatically by module load for the node it is running on. This makes sure that the spack or spack-user module has right compilers and default configuration selected for the node.

Warning

Cross-compiling packages for a different CPU architectures than the node spack is running on is error prone when it is possible (some combinations are impossible) and should be avoided when possible. The one exception to this is compiling packages for a compatible CPU with less features than the CPU on the node spack is running on (e.g. compiling for skylake_avx512 on a cascadelake node), but even this requires care. Also, cross-linux-distro builds (compiling for rocky8 on centos7) are outright impossible with Spack.

The nodes currently supported for Spack and their architecture and partitions are given in the tables organized by cluster in the sections below. Note that to reduce the total number of separate architectures, some are grouped together and rounded down to the lowest common denominator for CPU architectues and the minimum for CUDA architectue. For example, the lowest common denominator of CPU architectures haswell and broadwell is haswell, and CUDA architectures 70 and 75 is 70.

NHR

NodesCPU and OSArchitecture/TargetFabriccuda_archPartitions
Emmy Phase 1linux-centos7-skylake_avx512OPAmedium40*, large40*
Emmy Phase 2linux-centos7-cascadelakeOPAstandard96*, large96*, huge96*
Emmy Phase 3linux-rocky8-sapphirerapidsOPAmedium96s*, standard96s*, large96s*, and huge96s*
Grete Phase 1 (ggpu0X)linux-rocky8-skylake_avx512IB70grete* except grete
Grete Phase 2 (ggpu1XX, ggpu2XX)linux-rocky8-zen2IB80grete*

SCC

NodesCPU and OS Architecture/TargetFabriccuda_archPartitions
ampXXXlinux-scientific7-cascadelakeOPAmedium, int
dfaXXX, dsuXXX, gwdeXXXlinux-scientific7-haswellmedium, fat, fat+
agqXXX, agtXXXlinux-scientific7-cascadelakeOPA70gpu
dgeXXXlinux-scientific7-broadwell52gpu, gpu-int, vis
dbnXXlinux-rocky8-zen3IBcidbn
hhXXXlinux-rocky8-zen2RoCEhh
saXXXlinux-rocky8-haswellRoCEsa
sgizXXXlinux-scientific7-skylake_avx512IBint, sgiz

The lowest common denominators by partition are

PartitionCPU and OS Architecture/TargetFabriccuda_arch
mediumlinux-scientific7-haswellOPA or nothing
fatlinux-scientific7-haswell
fat+linux-scientific7-haswell
intlinux-scientific7-skylake_avx512OPA or IB
gpulinux-scientific7-broadwellOPA or nothing61
gpu-intlinux-scientific7-broadwell52
vislinux-scientific7-broadwell52
hhlinux-rocky8-zen2RoCE
salinux-rocky8-haswellRoCE
sgizlinux-scientific7-skylake_avx512IB