SPACK für Nutzersoftware

SPACK

zum Bauen von Nutzer-Software

Allgemeines

Mit dem Umstieg auf RHEL 9wechseln wir auch auf SPACK zur Erstellung des zentralen Modulsystems.

SPACK ermöglicht es aber auch, viele verschiedene Softwarepakete schnell und einfach als Nutzer selbst zu bauen – die bei Spack verfügbaren sehen Sie mit „spack list <name>“.

Da die systemweite SPACK-Installation für das zentrale Modulsystem konfiguriert ist, müssen dafür aber einige der Standardeinstellungen modifiziert werden.

SPACK bietet dafür zwei Möglichkeiten: Environments oder nutzerspezifische Konfigurationsdateien in ~/.spack/.
Wir empfehlen Environments, wie im Folgenden beschrieben.

Anlegen:

 spack env create <$HOME/Pfad/zum/Environment>

Zum Beispiel, wenn man das Environment „Mein_Env“ nennen möchte:

 spack env create $HOME/Mein_Env

_{oder – wenn man sich schon im entsprechenden Verzeichnis befindet – einfach}

 spack env create .

Zum Beispiel, wenn man das Environment „Mein_Env“ erstellen möchte:

 mkdir -p $HOME/Mein_Env
 cd Mein_Env
 spack env create .

Bitte beachten Sie, dass Sie einen Pfad angeben müssen. Wenn Sie nur einen Verzeichnisnamen angeben, interpretiert Spack dies als sogenanntes „managed Environment“. Dies führt zu einem Fehler, da in diesem Fall das Verzeichnis für das Environment in einem Unterverzeichnis der Spack-Installation erstellt werden sollte, das jedoch in einem schreibgeschützten Dateisystem sich befindet.

Aktivieren:

Das Environment wird dann mit

 spack env activate <$HOME/Pfad/zum/Environment>

_{oder über seinen symbolischen Namen}

 spack env activate Mein_Env

aktiviert.

^{Statt „spack env activate“ kann man synonym auch den kürzeren Alias „spacktivate“ benutzen.}

Deaktivieren:

 spack env deactivate

^{(oder der kürzere Alias „despacktivate“)}

entlädt das Environment, was die verfügbaren Module wieder auf die des zentralen SPACK-Modulsystems reduziert.

Achtung, wichtiger Hinweis!

Vor dem Deaktivieren eines Environments müssen alle mit „spack load <Paketname>“ geladenen Pakete mit „spack unload <Paketname>“ entladen werden, da sonst die Arbeitsumgebung unübersichtlich werden und viele Programme unbrauchbar werden können.

Konfiguration für SPACK Environment

Im neu erzeugten Environment muss die Konfiguration angepasst werden: „spack config edit“.

Alternativ kann die <$HOME/Pfad/zum/Environment>/spack.yaml-Datei mit einem Texteditor Ihrer Wahl bearbeitet werden.

Die Konfiguration sollte wie folgt angepasst werden („# …“ kennzeichnen Kommentare, die weggelassen werden können):

Konfiguration in spack.yaml

# This is a Spack Environment file.
#
# It describes a set of packages to be installed, along with
# configuration settings.
spack:
##### Config Settings #####
  config:
    install_tree:
      root: ~/myspackapps
    build_jobs: 16
    build_stage:
    - $tempdir/$user/spack-stage
    - $user_cache_path/stage
    test_stage: $user_cache_path/test
    source_cache: ~/spackapps/cache
    misc_cache: $user_cache_path/cache
  packages:
    all:
      permissions:
        read: group
        write: group
        group: <YOUR USERID/TUID> # alternatively the GROUPID related to a project dir you want to use, need to change install_tree, too
    gcc:
      buildable: true
    llvm:
      buildable: true
    intel-oneapi-compilers:
      buildable: true
  upstreams:
    spack-instance-1:
      install_tree: /shared/spapps
      modules:
        lmod: /shared/spmodules
  
##### Config Settings End #####

  # add package specs to the `specs` list
  specs: []
  
  view: false
  concretizer:
    unify: when_possible
    reuse: true

Alle Parameter in <…> bitte durch eigene Werte ersetzen!

Lösung für ein mögliches Problem mit dem compiler-wrapper Paket

Es ist bei uns oft passiert, dass Spack das compiler-wrapper Paket in dem falschen Verzeichnis (und zwar in dem aktuellen Installation-Verzeichnis und nicht in dem System-Installation-Verzeichnis) sucht.

Man kann aber ein Symlink am korrekten Verzeichnis erzeugen.

Zum Beispiel:
cd ~/myspackapps

mkdir -p none-none

cd none-none

ln -s /shared/spapps_2026_01/none-none/compiler-wrapper-1.0-gcmeg6dovnmrpdtnjuynfnmq3pdilj2h

Ein ähnliches Vorgehen könnte auch bei anderen Paketen erforderlich sein, wie, z.B., gmake.

Dies ist eine vorübergehende Lösung; in der Regel sollte dieses Problem nicht auftreten.

SPACK env ist „additiv“

Mit dieser Konfiguration (siehe „upstreams:“) eines eigenen SPACK-„Environments“ aktivieren Sie ihre eigene Software zusätzlich zu den SPACK-Modulen des zentralen Modulsystems – es wird dabei nicht ausgeblendet oder inaktiv.

Softwaremodule mit SPACK

Eigene Software-Pakete (in Spack-Speak „specs“) können Sie Ihrem Environment auf zweierlei Weise hinzufügen: per spack-Befehl oder über das direkte Editieren der <$HOME/Pfad/zum/Environment>/spack.yaml-Datei, wobei letzteres vor dem Aktivieren erfolgen muss).

Mit

 spack add gcc@8 %gcc@11.4.1

fügen Sie z.B. den GCC hinzu.

Sind alle „specs“ für das Environment definiert, stößt

 spack install

deren Build an (also den Kompilier- und Installiervorgang).

Was @ und % bedeuten

Die Spack-Syntax mit „@“ and „%“ bedeutet:

software@version = erzeuge die gewünschte Software in genau der gewünschten Version
%compiler@version = mit diesem Compiler in genau dessen angegebener Version

Mit dem „:“ (Doppelpunkt) können Sie auch „von-bis-Bereiche“ für Versionen vorgeben:

software@1:3 = erzeuge die Software in Version 1, 2 oder 3

Lassen Sie die Angabe „@version“ ganz weg, nimmt Spack die jüngste Version sowohl von „software“ als auch vom „%compiler“ an (bzw. die für dieses „software“-Paket „bevorzugte“ Compilerversion).

LMod-kompatible Modulfiles

Sie können SPACK auch dazu verwenden, LMod-kompatible Modulfiles für Ihre selbstgebaute Software zu erzeugen. Dazu müssen Sie in der <$HOME/Pfad/zum/Environment>/spack.yaml-Datei ein geeignetes Verzeichnis dafür vorgeben:

  modules:
    default:
      roots:
        lmod: ~/myspackmodules

Mit diesem Eintrag erzeugt Spack „LMod“-kompatible Module im angegebenen Verzeichnis, die dann per „module load“ geladen werden können.

Um dieses zusätzliche Modul-Verzeichnis mit den „module“-Kommandos nutzen zu können, muss es LMod noch mittels

module use ~/myspackmodules

bekannt gemacht werden.

Links & Referenzen

Besonderheiten

Dedizierter Software-Stack auf `gaoc000[1-3]`

Achtung: Da die CPUs der GPU-Knoten gaoc000[1-3] (NVidia DGX) keine Unterstützung für AVX-512-Befehle bieten (nur AVX-2), mußte für diese Knoten ein eigener Software-Stack erstellt werden, der nur auf dem Systemcompiler basiert und weniger Programme und Bibliotheken als der normale Software-Stack umfasst. Die Module dieses Software-Stacks sind nach der Ausführung des Befehls

export MODULEPATH=/shared/spmodules_2026_01_avx2/linux-rhel9-x86_64/Core

zugreifbar.

Wenn Sie NVidia-GPUs des Typs „Ampere“ mit Programmen nutzen wollen, die AVX-512 voraussetzen, können Sie die DGX-Knoten für Ihre Jobs mittels

#SBATCH -C avx512

vermeiden.