FAQ - Häufig gestellte Fragen zu "Software"

MIt dem Kommando „module avail“ oder „module spider“ kann man sich alle global installierten Programmpakete in allen installierten Versionen anzeigen lassen.

Das module -Kommando lädt und entlädt Pfade und Umgebungsvariablen und zeigt verfügbare Software an.

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 Nutzer_innen 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 Ihrem persönlichen $HOME- oder in einem gemeinsamen Projekt-Verzeichnis installieren.

Nein: Sie müssen prüfen, ob die SW 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-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 erlaubt, was möglich ist.

Kommt drauf 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 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 erlaubt, was 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>
gdb /pfad/zum/programmBinary core.<PID>

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

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 Pogramme nach Linux-Versionen: Wenn es wirklich wissenschaftliche Programme sind, ist die Chance sehr hoch, 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 Linux-Distribution 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.