MIt dem Kommando „module avail“ (bzw. „module spider“) kann man sich alle global installierten Programmpakete, Werkzeuge und (wiss.) Bibliotheken in allen installierten Versionen anzeigen lassen.

Das „module“-Kommando lädt und entlädt Pfade und Umgebungsvariablen für die jeweilige Software/Version.

Eine detaillierte Beschreibung finden Sie hier .

Wir haben unser Modulsystem in Form eines hierarchischen Baums gestaltet, bei dem viele (OpenSource-) Software-Pakete erst nach dem Laden eines (passenden) Compilers und ggf. eines (passenden) MPI-Moduls sicht- und ladbar werden.

Wenn Sie bisher weder das eine noch das andere geladen haben, tauchen also viele Pakete gar nicht in der Ausgabe von „module avail“ auf.

Wenn Sie eine Software vermissen, probieren Sie also zuerst die Kommandos

module spider <meineSW> oder
module spider | grep -i meineSW oder
module --show-hidden avail <meineSW>

aus.

Erst wenn Ihr gewünschtes Paket auch hier nicht auftaucht, müssen Sie selbst installieren oder ein Ticket aufmachen.

Schreiben Sie uns eine Mail an hhlr@hrz.tu-darmstadt.de. Wenn davon auszugehen ist, dass das Programm von genügend anderen Nutzern oder Gruppen benötigt wird, werden wir es in unserem Modulbaum global installieren.

Ansonsten können wir Sie (mit vertretbarem Aufwand) bei einer lokalen Installation z.B. in Ihrem /home/-Verzeichnis beraten und unterstützen.

Selbst installieren

Da unter Linux keinerlei administrative bzw. erhöhte Privilegien für die Installation von normalen Benutzerprogrammen erforderlich sind, können Sie einfach der Dokumentation Ihres Programms (README- oder INSTALL-Dateien) folgen und es in Ihr persönliches $HOME- oder in einem gemeinsamen Projekt-Verzeichnis installieren.

LMod versucht, Ihre Anforderungen so schnell wie möglich zu erledigen, und hält dazu einen Cache in Ihrem Home-Verzeichnis vor, der leider kaputtgehen kann.

Symptom ist beispielsweise:

/usr/bin/lua: /opt/lmod/8.7.14/libexec/Cache.lua:341: bad argument #1 to 'next' (table expected, got boolean)

Um auf einen kaputten LMod-Cache zu testen, benennen Sie Ihr Cache-Verzeichnis um -

mv $HOME/.cache/lmod $HOME/.cache/lmod_X

und probieren Sie erneut ein „module avail“. Wenn es jetzt klappt, können Sie Ihren alten umbenannten Cache löschen:

rm -rf $HOME/.cache/lmod_X

denn LMod hat bereits einen neuen angelegt.

Kurz gesagt: nein – Sie müssen prüfen, ob die Software lizenzpflichtig ist und wenn ja, ob Sie zur Nutzung einer genügenden Anzahl von Lizenzen berechtigt sind. Das wäre zum Beispiel der Fall, wenn sich Ihr Institut an den jährlichen Kosten einer TU-weiten Campus-Lizenz beteiligt oder eine eigene Lizenz erworben hat.

Bitte beachten Sie auch die Hinweise zu Lizenzen in dieser Liste.

Grundsätzlich gilt: Es ist nicht alles auch legal, was technisch möglich ist.

Kommt darauf an.

Häufig werden in unseren Modulen für kommerzielle Programme Lizenzen auf den Lizenzservern der TU Darmstadt angesprochen. Diese Lizenzen stehen in der Regel exklusiv den Mitgliedern der TU zur Verfügung, die sich z.B. an den Lizenzkosten beteiligen. Im Einzelfall können Sie uns zur Abklärung eine E-Mail an hhlr@hrz.tu-…senden. Wir können Sie z. B. dabei unterstützen, Lizenzen von eigenen Lizenzservern Ihres Instituts zu ziehen.

Grundsätzlich ist nicht alles auch legal, was technisch möglich ist.

Entfernen Sie alle nicht unbedingt nötigen Module – ein Jobscript sollte immer mit

_______________

module purge
module load <nur unbedingt notwendige Module>

_______________

beginnen, um eine „saubere“ Umgebung sicherzustellen.

Achtung: Wenn Sie auf dem Loginknoten Module laden (manuell oder automatisiert via .bashrc) und aus dieser modifizierten Umgebung heraus einen Job abschicken, erbt dieser Job die Einstellungen!
Insbesondere deswegen ist das o.a. Vorgehen empfohlen.

Analysieren Sie die zur Laufzeit Ihres Programms aktiven Libraries („shared objects“) mittels

ldd -v /pfad/zum/binary

Eventuell enthält Ihr $LD_LIBRARY_PATH doch noch ein Verzeichnis mit einer falschen oder veralteten Library, die eigentlich aus einem der geladenen Module kommen sollte.

Insbesondere der berüchtigte „Bus error“ stammt häufig von nicht (mehr) passenden Übergabewerten/Strukturen zwischen aufrufendem Binary und aufgerufener Library, die zu „verschobenen“ Speicherzugriffen und damit zum Absturz führen.

Prüfen Sie Ihre Eingabe- und Parameterdateien auf falsche DOS/Windows-Zeilenende-Zeichen . Die Linux-Version eines wissenschaftlichen Programms kommt oft mit der Windows-Kombination aus CR/LF nicht zurecht, während das die Windows-Version desselben Programms natürlich vor keine Probleme stellt.

Ein Programmabbruch erzeugt normalerweise ein Speicherabbild / core dump (unter Linux meist als Datei namens core.<PID> in dem Directory, wo es gestartet wurde).

Leider hatte das (manchmal auftretende) massenhafte Schreiben von Coredumps durch fehlerhaft aufgerufene (oder geschriebene) Programme heftige Auswirkungen auf unser cluster-weites GPFS-Dateisystem , so dass wir das Schreiben von Coredumps abgeschaltet haben.

Damit Sie jedoch Ihre Software trotzdem debuggen können, sind Coredumps nur abgeschaltet, nicht untersagt, und können wieder aktiviert werden:

ulimit -Sc unlimited
<mein problematisches Programm aufrufen>
ml gcc
gdb /pfad/zum/programmBinary core.<PID>

Im GNU Debugger können Sie dann mit „bt“ einen Stacktrace der letzten Systemaufrufe vor dem Crash erhalten.

Wenn es sich wirklich um dasselbe (und nicht nur das gleiche) Binary handelt, vergleichen Sie gegenseitig

• Ihre jeweiligen Jobscripts
• die geladenen Module, die Sie vor dem Abschicken des Jobs (manuell oder automatisch) geladen hatten:
  module list
  (denn diese werden dem daraus abgeschickten Job vererbt)!
• Ihrer beider Shell-Environment:
  env | sort > myEnv
• Ihrer beider $LD_LIBRARY_PATH, bzw. die tatsächlich zur Laufzeit geladenen Libraries
  ldd /path/to/same/binary

Die GNU C library ist eine grundlegende Komponente unter Linux (wird vom Betriebssystem mitgeliefert), und wird von fast jedem Binärprogramm benötigt.

Von Zeit zu Zeit müssen wir das Cluster auf eine neue Betriebssystem-Hauptversion heben (major release) und stellen im Zuge der Vorbereitungen darauf bereits einige Login- und ggf. Rechenknoten darauf um.

Wenn Sie (in solchen Übergangszeiten oder nach einfachem Kopieren eines Binärprogramms aufs Cluster) Fehler wie:

 ./my-binary: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.XX' not found (required by ./my-binary)

erhalten, versuchen Sie höchstwahrscheinlich, ein auf einem jüngeren Betriebssystem kompiliertes Binary auf einem älteren auszuführen.

Entweder Sie wechseln wieder auf den Loginknoten mit dem jüngeren Betriebssystem (wo Sie kompiliert haben), oder Sie übersetzen die Software nochmal auf einem der älteren Loginknoten.

Ja, das geht mit Hilfe der sogenannten „collections“ von LMod, unserem Modulsystem .

Details dazu finden Sie in unserer Tipps und Tricks -Sektion, und in der Man-Page von module („man module“).

Auf dem Lichtenberg HPC läuft ausschließlich Linux, darum können native Windows-Executables dort nicht ausgeführt werden, ebensowenig wie MacOS-Binaries.

Fragen Sie die Hersteller Ihrer Programme nach Linux-Versionen: Wenn es wirklich wissenschaftliche Programme sind, ist die Chance sehr groß, dass sie eine haben.

Wegen des unverhältnismäßig großen Aufwands unsererseits (und der fehlenden Lizenzen) können wir Anfragen nach „virtuellen Windows-Maschinen auf dem Cluster“ oder mal eben WINE zu installieren leider nur abschlägig bescheiden.

Da der Lichtenberg-HPC mit der RedHat Enterprise Linux-Distribution (RHEL) läuft, ist sein natives Installationsformat RPM, nicht .deb.

Obwohl es Mittel und Wege gibt, .deb-Pakete nach .rpm zu konvertieren bzw. sogar auf RPM-basierenden Distributionen zu installieren (siehe die Informationen zum „alien“-Kommando im Web), führen solche „Fremdpakete“ oft zu Problemen und Seiteneffekten. Daher können solche Fremdpakete nicht auf den Lichtenberg-Knoten installiert werden.

Wenden Sie sich an den Hersteller der Software, um sie in einer Form zu erhalten, die sich ohne Installation über das Betriebssystem nutzen läßt (z.B. eine .zip- oder .tar-Datei).

Falls ihr Quellcode verfügbar ist, versuchen Sie, die Software selbst zu übersetzen.

Wir überarbeiten diese Seite von Zeit zu Zeit.

Bitte senden Sie uns Ihre noch unbeantwortete Frage als E-Mail an hhlr@hrz.tu-…. Dann können wir sie beantworten und bei allgemeinem Interesse hier aufnehmen.