FAQs software

Diese Seite ist noch im Aufbau.

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.

Global installierte Programme

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

Schreiben Sie uns eine email 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, z.B. ob sich Ihr Institut an den jährlichen Kosten einer TU-Lizenz beteiligt. Bitte beachten Sie auch die Hinweise zu Lizenzen in dieser Liste

Grundsätzlich 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.

Laufzeitprobleme

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 Loginnode 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.

Andere Software-Fragen

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 -c 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

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.