FAQs software

FAQ – Häufig gestellte Fragen zu „Software“

Installation

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

Das Kommando module 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 . Wenn davon auszugehen ist, dass das Programm von genügend anderen NutzerInnen 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.

Lizenzen

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 mail an 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.

Laufzeit-Probleme

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.

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 die 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 Tips und Tricks-Sektion, und in der Man-Page von module („man module“).

Maschinen-Architektur

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 CentOS läuft (einer RedHat-kompatiblen Distribution), 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), sind wir nicht in der Lage, solche Fremdpakete zu unterstützen. Wenden Sie sich an den Hersteller oder versuchen Sie, die Software (sofern ihr Quellcode verfügbar ist) selbst zu übersetzen.

Sonstige

Wir überarbeiten diese Seite von Zeit zu Zeit.

Bitte senden Sie uns Ihre Frage als email an . Dann können wir sie beantworten und gegebenenfalls hier aufnehmen.