Nutzung der Software

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 openmpi/intel 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 avail
    Zeigt alle verfügbaren Software-Module an.
  • 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, oder mit module avail openmpi/gcc alle OpenMPI-Module sehen, die für den GCC geeignet sind.
  • module list
    Zeigt die derzeit geladenen Software-Module an.
  • module whatis Modul-Namen
    Zeigt kurze Beschreibungen der genannten Module an. Listet ohne Parameter alle Module auf.
  • module help Modul-Namen
    Zeigt (falls vorhanden) weitere Beschreibungen der genannten Module an.
  • 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.
    Tipp: Man kann sich das Laden der immer wieder benötigten Module auch in der eigenen '~/.bashrc' Datei vorkonfigurieren.
  • module unload Modul-Namen
    Entlädt die geladenen Module. Danach steht die entsprechende Software nicht mehr zur Verfügung.
  • 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 mit einer klar definierten 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 die Module zu laden, die für diesen Job wirklich benötigt werden.

Änderungen ab 1. 4. 2019

Während der Downtime am 1. 4. 2019 stellen wir unser Software-Modulsystem auf einen hierarchischen Modulbaum um.
Dieser Typ ist für Sie wesentlich übersichtlicher (und lässt sich viel leichter und weitgehend automatisiert bauen, insbesondere bei Änderungen in den gegenseitigen Abhängigkeiten der Module voneinander).

Für Sie ändert sich

  • dass Module jetzt in Abhängigkeit von anderen Modulen quasi automatisch sichtbar werden bzw. verborgen bleiben.
    Ungünstige bzw. widersprüchliche Modulkombinationen werden schon beim automatisierten Bauen berücksichtigt und können so besser als zuvor vermieden werden.
  • dass compiler-abhängige Module jetzt automatisch mit jeder unterstützten Version aller unterstützten Compiler gebaut werden. Sie erhalten so nicht nur Module, die mal mit irgendeiner Version des geladenen Compilers übersetzt wurden, sondern mit genau derjenigen Version, die Sie beim Compiler-Laden erhalten haben.
  • dass der Modulbaum jetzt aktuellere Versionen der unterstützten Module enthält.
  • dass wir für diverse Module darum jetzt auch jüngere Standardversionen gesetzt haben (also das, was geladen wird, wenn Sie keine Version angeben).
    Bitte beachten Sie, dass sich dadurch auch das Verhalten von Jobs ändern kann, die ab 1. 4. aus lange etablierten Jobskripts gestartet werden (sofern diese „module load <modul ohne Versionsnummer>“-Kommandos enthalten)!

Für den Fall, dass von Ihnen benötigte Module im neuen Software-Baum (noch) nicht verfügbar sind, können Sie für eine begrenzte Zeit mittels
export MODULEPATH=/shared/old_apps/modules/
den alten Modulbaum nutzen.

Jobskripte, die Sie dann aus dieser Session submittieren, erben die Einstellung und nutzen den alten Modulbaum. (Nur die aktuelle Session wird beeinflusst. Wenn Sie sich neu einloggen, sehen Sie wieder die neuen Module.)

Sichtbarkeit und Verfügbarkeit abhängiger Module

Der Befehl „module spider“ zeigt Ihnen alle verfügbaren Module an.

Der Befehl „module avail“ hingegen zeigt Ihnen jetzt nur noch die Module an, die Sie gerade -- also in Abhängigkeit von anderen (nicht) geladenen Modulen -- laden können.
Manche Programme und Bibliotheken werden jetzt nämlich erst sichtbar, wenn Sie sich für einen Compiler bzw. für eine MPI-Implementierung entschieden haben. Manche Module erhalten durch andere Module auch zusätzliche Funktionalitäten.

Beispiel: Laut „module spider“ gibt es das Modul fftw. Es taucht aber erst in der Ausgabe von „module avail“ auf, nachdem Sie mittels „ml gcc“ oder „ml intel“ einen Compiler geladen haben. Wenn Sie nun „ml fftw“ ausführen, erhalten Sie ein fftw-Kompilat, das mit genau dieser Compilerversion übersetzt wurde.
Falls Sie zusätzlich eines der Module openmpi oder intelmpi laden (egal ob zuvor oder danach), erhalten Sie das genau zum Compiler passende fftw-Kompilat, aber nun mit entsprechender MPI-Unterstützung.

Umbenannte oder entfernte Module

Wir haben manche Module umbenannt, um die neue Struktur zu ermöglichen und übersichtlich zu gestalten, und bieten einige alte Versionen nicht mehr an. Wenn Sie davon betroffen sind, müssen Sie Ihre Jobskripte wie folgt anpassen:

Altes Jobskript:

 module load gcc/4.9.4
module load openmpi/gcc/3.1.3/4.9.4
module load fftw/openmpi/3.3.5

Neues Jobskript:

 ml gcc/4.9.4 openmpi/3.1.3 fftw/3.3.8

Für bash-Experten: „Kompatibel mit alt und neu”:

 module load gcc/4.9.4
module whatis openmpi/3.1.3 &>/dev/null && ml openmpi/3.1.3 || ml openmpi/gcc/3.1.3/4.9.4
module whatis fftw/3.3.8    &>/dev/null && ml fftw/3.3.8    || ml fftw/openmpi/3.3.5 

Selbst erstellte Software, die gegen OpenMPI und/oder Slurm gelinkt ist

Falls Sie selbst Software gegen OpenMPI gebaut haben, müssten Sie diese mit einem der neuen openmpi-Module neu übersetzen. Das sollte schon vor dem 01. April möglich sein.
Die neuen Kompilate werden aber u.U. nicht optimal funktionieren (im Hinblick auf mpirun/srun), bis die neue SLURM Version aktiv ist.

Da wir kein „Testcluster“ mit dem neuen SLURM anbieten können, werden Sie Ihre neuen Kompilate in vollem Umfang (und gegen die neue Slurm-Version) allerdings erst nach dem 1. April testen können. Ist das erforderlich, bleibt Ihnen leider nur übrig, Ihre Warteschlange vor dem 1. April zu leeren, die neuen Kompilate ab dem 2. 4. zu testen und danach neue Jobs zu submittieren.

Bitte , wenn Sie Hilfe oder Unterstützung benötigen oder auf Probleme stoßen – wir helfen gern.