Environment-Modules auf Hummel
Auf dieser Seite werden Besonderheiten der Environment-Modules auf Hummel erklärt, siehe auch Grundwissen - Environment-Modules.
- Spezielles zu Programmierumgebungen
- Programmierumgebungen und Applikationen
- NetBSD Packages Collection (pkgsrc)
- Eigene Module-Umgebungen
Spezielles zu Programmierumgebungen
Unter einer Programmierumgebung verstehen wir im wesentlichen die Kombination von Compiler-Familie und MPI-Implementierung (zusätzlich gibt es Umgebungen die auf der NetBSD Packages Collection (pkgsrc) basieren; weitere Komplexität ergibt sich durch CUDA). Module für Programmierumgebungen heißen
. Voreingestellt ist die Programmierumgebung env
/Umgebungenv/system-gcc
, die lediglich den durch die Linux-Distribution bereitgestellten GNU-Compiler enthält.
Moderne Programmiersprachen und MPI bringen es mit sich, dass Unterprogramm-Bibliotheken im allgemeinen nicht mehr modular sind: sie sind häufig nicht unabhängig vom Compiler und/oder der gewählten MPI-Implementierung einsetzbar. Die (potentielle) Nicht-Modularität haben wir in unserer Module-Umgebung folgendermaßen berücksichtigt:
- Unterprogramm-Bibliotheken stehen für jede
env
/Umgebung separat zur Verfügung. Technisch geschieht dies durch Erweiterung des Modul-Suchpfades. Beim Entladen vonenv
/Umgebung werden alle geladenen Bibliotheken entladen und der Suchpfad wieder entsprechend verkürzt. - Es kann nur ein
env
-Modul zur Zeit geladen sein. - Zunächst ist immer ein
env
-Modul geladen. Damit wirdmodule switch env/alteUmgebung env/neueUmgebung
bzw.module switch env env/neueUmgebung
zum üblichen Kommando (und nichtmodule load env/neueUmgebung
; alteUmgebung braucht nicht angegeben zu werden). Beiswitch
werden alle geladenen Bibliotheken entladen und automatisch in der neuen Umgebung geladen (falls sie in der neuen Umgebung vorhanden sind). Mitmodule unload env # entlädt env/alteUmgebung und ggf. Bibliotheken module load env # lädt env/defaultUmgebung aber keine Bibliotheken
wird die default-Umgebung wieder hergestellt.
Programmierumgebungen und Applikationen
Falls das Modul für einer Applikation ein env
-Modul
erfordert (typischerweise zur Ausführung von mpirun
),
wird das env
-Module nicht automatisch geladen (um zu
erzwingen, dass der Anwender sich darüber bewusst ist, dass die
Umgebung gewechselt wird). Ggf. muss die Umgebung für jede Applikation
gewechselt werden. Beispiel:
module switch env env/Umgebung1 module load Applikation1 mpirun Applikation1 module switch env env/Umgebung2 module load Applikation2 mpirun Applikation2
Ob eine Umgebung geladen werden muss, kann man auf zwei Weisen erfahren:
module display Applikation # benötigte Umgebung wird als prereq angezeigt module load Applikation # benötigte Umgebung wird in Fehlermeldung genannt
NetBSD Packages Collection (pkgsrc)
Die NetBSD Packages Collection (pkrsrc) ist eine Sammlung freier Software im Quellcode. Mithilfe dieser Sammlung kann Software, die von vielen weiteren Paketen abhängt, einfach bereitgestellt werden. Auf Hummel wird pkgsrc insbesondere eingesetzt, um Software-Pakete bereitzustellen, die üblicherweise in der Linux-Distribution verfügbar sind. Da pkgsrc-Pakete im globalen Software-Verzeichnis abgelegt werden, bleibt das System-image klein, d.h. es belegt wenig Hauptspeicher.
Module, die pkgsrc einbinden, enthalten in ihrem Namen
YYYYQ
Q (Jahr und Quartal, in dem die
Paketsammlung veröffentlicht wurde),
zum Beispiel env/2015Q2-gcc-openmpi
. Wer neu anfängt, sollte die
neueste Paketsammlung einsetzen. Ältere Sammlungen bleiben erhalten, um Kontinuität
sicherzustellen.
Für das Arbeiten mit pkgsrc ist die
Selbst-Dokumentation
von Modules hilfreich: Über module help
erfährt man, welcher Compiler und welches MPI zum Einsatz kommen, sowie
wie man eine Liste der in pkgsrc installierten Pakete anzeigen
lassen kann. Eine vollständige Liste der Software, die im Rahmen
von pkgsrc installiert werden kann findet man auf
der pkgsrc-Web-Seite.
Fehlende pkgsrc-Pakete können vom
HPC-Team leicht nachinstalliert
werden.
Eigene Module-Umgebungen
Eigene Umgebungen kann man sich auf zwei Weisen einrichten:
- Laden der benötigten Module in
$HOME/.profile
. Diese Umgebung steht dann in jeder interaktiven Sitzung und jedem Batch-Job zur Verfügung. - Anlegen eines eigenen Module-Verzeichnisses:
mkdir $HOME/modules module use --append $HOME/modules
In $HOME/modules
kann man links auf existierende
Module einführen, um mit kürzeren Namen arbeiten zu können, zum
Beispiel
cd $HOME/modules ln -s /sw/BASE/env/cuda-7.0.28_system-gcc_openmpi-1.8.8 cuda module unload env module load cuda # statt: module load env/cuda-7.0.28_system-gcc_openmpi-1.8.8
Mit den env
-Modulen kann man immer nur einen Compiler zur
Zeit auswählen (der zweite Compiler ist immer der
system-gcc
). Auf folgende Weise kann man mit einem
neueren gcc
und dem Intel-Compiler arbeiten:
cd $HOME/modules ln -s /sw/BASE/env $HOME/modules/myenv module unload env module load myenv/gcc-5.0.2 module load myenv/intel-15.0.3_impi-5.0.3
Bei diesem Vorgehen, muss man allerdings selbst auf die Konsistenz
der Umgebung und der einzubindenden Bibliotheken
in /sw/LIB
achten.