Nutzung der Software: Environment-Module

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 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 zu empfehlen, Jobskripts 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 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“), 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..

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)