Nutzung der Software: Environment-Module

Der hier im weiteren beschriebene Software-Stack ist auf dem cluster-weiten zentralen Filesystem installiert, und steht somit auf allen Login- und Rechenknoten gleichermassen zur Verfügung.

Initialisieren und Laden

Auf dem Lichtenberg-Cluster stehen verschiedenste Compiler, (wissenschaftliche) Bibliotheken und sonstige (Anwendungs-) Software zur Verfügung. Für jedes dieser Pakete sind separate Einstellungen hinsichtlich $PATH, $LD_LIBRARY_PATH und sonstiger Umgebungsvariablen nötig (die sich gegenseitig ungünstig beeinflussen oder gar ausschließen können).

Außerdem brauchen verschiedene Nutzer(gruppen) und Programme verschiedene Versionen derselben Software, die sich eigentlich nicht parallel installieren und nutzen lassen.

Aus diesen Gründen werden die Einstellungen pro Software-Paket und -Version in sogenannten „Environment-Modules“ gekapselt, die bei uns das Modulsystem „LMod“ verwaltet. Diese Module haben nichts mit 'perl'- oder 'python'-Modulen zu tun und sollten nicht damit verwechselt werden.

Die aktuell verfügbare Software kann über das Modul-System aufgelistet, geladen und entladen werden. Dazu gibt es das Kommando „module“.
Mit „module help“ erhält man eine Übersicht aller Parameter des Befehls.

Im Folgenden entspricht der Parameter Modul-Name (mindestens einem Element) der Ausgabe von „module avail“.

Man kann ausdrücklich die gewünschte Version eines Pakets angeben oder auch Kurzformen wie z.B. „module load gcc“ oder „module load intel-oneapi-compilers openmpi“ benutzen, womit man (bei Angabe nur des Namens der Software) die derzeit als Standard gesetzte (default) Version erhält. Diese Standardversionen sind mit einem (D) in der Liste aller Module gekennzeichnet.

  • module load Modul-Namen
    Lädt die genannten Software-Module. Erst nach dem Laden des Moduls bzw. aller erforderlichen Module steht die entsprechende Software zur Verfügung.
  • module unload Modul-Namen
    Entlädt die geladenen Module. Danach steht die entsprechende Software nicht mehr zur Verfügung.
  • module avail
    Zeigt alle derzeit ladbaren Software-Module an, abhängig von zuvor (noch nicht) geladenen Modulen
  • module avail Modul-Name
    Zeigt alle verfügbaren Versionen der genannten Software an.
    So kann man z.B. mit module avail gcc alle verfügbaren Versionen von GCC auflisten
  • module list
    Zeigt die derzeit geladenen Software-Module an.
  • module help Module_Names
    Zeigt (falls vorhanden) weitere Beschreibungen der genannten Module an.
  • module help
    Zeigt die gesamte Hilfe zum „module“-Kommando an
  • module whatis Modul-Namen
    Zeigt kurze Beschreibungen der genannten Module an. Listet ohne Parameter alle Module auf.
  • module spider
    Zeigt alle Module an (ob zur Zeit ladbar oder nicht).
  • module spider Modul-Namen
    Zeigt alle verfügbaren Derivate des Moduls an. Gibt man mit „module spider Modul-Name/Version“ auch noch eine konkrete Versionsnummer an, sieht man alle Kombinationen von Abhängigkeiten, in denen Derivate des angegebenen Moduls verfügbar sind.
  • module switch Modul-Nameneu oder module switch Modul-Namealt Modul-Nameneu
    Schaltet die Version eines geladenen Moduls (alt) auf die angegebene Version (neu) um. Ähnelt dem Paar module unload / module load, behält aber die Reihenfolge der geladenen Module bei.
  • module purge
    Entlädt alle geladenen Software-Module.
    Empfohlen am Beginn eines Jobskripts vor allen „module load …“-Kommandos, um die Jobs mit einer klar definierten und reproduzierbaren Umgebung zu starten.

Kurzbefehl „ml“:

  • ml (ohne Parameter) = module list
  • ml Modul-Name(n) = module load Modul-Name(n)

Achtung: beim Submittieren von Batchjobs erben diese alle bereits geladenen Module aus Ihrer Login-Session! Es ist daher empfehlenswert, Jobscripts zuerst mit einem „module purge“ zu beginnen, um danach nur genau diejenigen Module zu laden, die für diesen Job wirklich benötigt werden.

In unserem Kapitel „Tipps und Tricks“ erfahren Sie

  • wie Sie das Laden von Modulen während des Logins automatisieren können
  • wie ein Set aus Modulen als „collection“ gespeichert und immer wieder mit nur einer Zeile im Jobscript geladen werden kann.

Sichtbarkeit und Verfügbarkeit abhängiger Module

Viele Module sind abhängig von einem Compiler bzw. einer MPI-Implementierung. Solche Module können nicht unmittelbar geladen werden – sie stehen erst nach Laden eines Compiler- bzw. eines MPI-Moduls zur Verfügung.

Das „module avail“-Kommando zeigt nur die Module an, die zur Zeit geladen werden könnten – abhängig von bereits (oder noch nicht) geladenen anderen Modulen.

Darum tauchen viele Programme und Bibliotheken erst dann auf, wenn Sie ein Compiler-Modul (und ggf. ein MPI-Modul) geladen haben. Einige Module werden sogar automatisch von nicht-MPI-fähig auf MPI-fähig umgestellt, sobald Sie eine MPI-Version laden.

Um diese „anfänglich versteckten“ Module trotzdem zu finden, benutzen Sie entweder „module spider“, das Ihnen alle Module im gesamten Modulsystem anzeigt.

Oder Sie fügen --show_hidden zum „ml avail“-Kommando hinzu:
module --show_hidden avail fftw

listet wiederum alle Module namens „fftw“ im gesamten Modulbaum auf.

Beispiel: Solange Sie noch kein Compiler-Modul geladen haben, taucht das „fftw“-Modul in der Ausgabe von „ml avail“ nicht auf. In „module spider“ jedoch wird es (mehrfach) angezeigt.

Sobald Sie aber ein bestimmtes Compiler-Modul geladen haben (via „ml gcc“ or „ml intel-oneapi-compilers“), erhalten Sie durch „ml fftw“ genau das fftw-Paket, das mit genau dem jetzt geladenen Compiler übersetzt wurde – nicht nur mit einem/r Compiler(version) aus dessen „Familie“.

Wenn Sie jetzt noch openmpi oder intelmpi laden (bevor oder nach ml fftw), wird das bisher nicht-MPI-fähige „fftw“ durch dessen gleiche, aber MPI-fähige Version ersetzt (immer noch von demselben Compiler übersetzt).

Um zu sehen, von welchen Modulen fftw abhängt, können Sie wiederum module spider fftw benutzen..

Auf Red Hat 9.6-Knoten sind Module, die von einer MPI-Implementierung abhängen, sofort sichtbar. Für einen korrekten Betrieb muss jedoch in den meisten Fällen das MPI-Paket geladen werden, bevor diese Module geladen werden.

Sollten noch weitergehende Fragen zum Modulsystem oder zu Software auf dem Cluster offen sein, – im Rahmen unserer Möglichkeiten helfen wir gern weiter.

Hintergrund

Dieser in Bezug auf Compiler und MPI hierarchische Modulbaum ist wesentlich konsistenter und leichter zu nutzen. Ebenso ist das Kompilieren und Warten einfacher, insbesondere im Hinblick auf die (leider häufigen) gegenseitigen Abhängigkeiten der Software-Pakete.

Vorteile für die Nutzer:

  • Module sind nur dann sicht- und ladbar, wenn ihre Voraussetzungen erfüllt sind (und bleiben unsichtbar/unladbar, falls nicht)
  • Ungünstige oder inkompatible Kombinationen von Modulen werden verhindert – schon vor dem Laden bzw. sogar schon beim automatischen Bauen der Software.
  • Software wird automatisch mit allen Compiler- und MPI-Versionen gebaut, die im Modulbaum verfügbar sind. Als Nutzer/in erhalten Sie somit immer exakt das Binary eines Programms, das mit genau der geladenen Compiler- und MPI-Version gebaut wurde.
  • jüngere Versionen der Software sind schneller verfügbar (durch das weitgehend automatische Bauen)

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.