Häufig gestellte Fragen

FAQ – Häufig gestellte Fragen zum Zugang

Benutzerkonto

Wenn Sie auf einem unserer Loginnodes angemeldet sind, zeigt das Kommando account_expire das Datum, an dem Ihr Nutzerzugang ausläuft.

Wir senden Ihnen eine automatische Mail 4 Wochen bevor Ihr Account ausläuft, und eine weitere am Tag des Auslaufens.

Um Ihren Nutzerzugang zu verlängern, füllen Sie bitte erneut den „Nutzungsantrag“ aus, und senden Sie ihn uns vollständig unterschrieben per Hauspost zu (bzw. über Ihren lokalen Ansprechpartner).

Zu unterscheiden ist, ob der gewählte Loginnode gar nicht antwortet (was auf seinen Ausfall oder Netzwerkprobleme hindeutet), oder ob er reagiert, aber Ihren Account nicht zulässt.

  • Versuchen Sie es auf einem anderen Loginknoten (der, den Sie probiert haben, könnte gerade ausgefallen sein)
  • Lesen Sie die (ssh-) Fehlermeldung genau und vollständig durch. Manchmal enthält sie das exakte Kommando, das Ihr akutes Problem behebt.
  • Versuchen Sie, sich gezielt über IPv4 or IPv6 anzumelden:
    ssh -XC –4 <tu-id@>lcluster15.hrz.tu-darmstadt.de
    ssh -XC –6 <tu-id@>lcluster17.hrz.tu-darmstadt.de

Wenn all das nicht funktioniert, eröffnen Sie bitte ein .

Projekte

  • Director of the institute: Most departments are organized into institutes (Fachgebiete). If this does not apply to your organization, please insert the dean, or a person with staff responsibility for the main research group.
  • PI: The principal investigator is responsible for the scientific aspects of the project. This can be the director as well as a junior professor, or post doc.
  • Main researcher/ Project manager: In general, this is the person who does the main part of work inthis project. He or she is the one who is responsible for the administrative aspects of the scientific project. He or she is the „technical contact“ the HRZ communicates with.
  • Additional researchers: All other researchers who can compute on this project account. This includes other PhD students as well as students, who are working for the project.

Inhaber/in eines Projekts, also Projektmanager/in, ist meist ein wissenschafltiche(r) Mitarbeiter/in. Dieser PM kann ihrem/seinem Projekt weitere Personen hinzufügen, z.B. Bachelor- oder Masterstudenten, oder Kollegen, mit denen gemeinsam an diesem Projekt gearbeitet werden soll.

Alle diese Mitnutzer/innen müssen ihr eigenes Benutzerkonto auf dem HLR haben, bevor sie dem Projekt hinzugefügt werden können.

Achtung: während Projekte ausdrücklich von mehreren genutzt werden können, ist es untersagt, ein Benutzerkonto zu teilen, also anderen Personen das Passwort oder den privaten ssh-Key zukommen zu lassen!

All projects are subject to a technical review by the HRZ. Middle and large projects are objected to an extended technical review, regarding, for example, the scalability of the code. Concerning scientific metrics, the “MIDDLE” projects will be reviewed by two TU Darmstadt experts, for “LARGE” projects one external reviewer frome outside TU Darmstadt and one internal reviewer will be consulted. Based on the reviews, the steering committee allocates the resources.

FAQ – Häufig gestellte Fragen zum Batch-System

Jobs vorbereiten

Nur mit diesen Pflichtangaben kann der Scheduler entscheiden, auf welchen Compute-Knoten er den Benutzerjob zur Ausführung bringt.

Wenn man z.B. kein --mem-per-cpu= angibt, würde ein Job mit sehr großen Hautspeicheranforderungen u.U. auf einem Knoten mit zu wenig RAM ausgeführt werden und abstürzen.

Um es „spielerisch“ auszudrücken: mit den Ressourcenanforderungen aller im Batchsystem eingestellten Jobs muss der Scheduler eine Art „multidimensionales Tetris“ spielen, um die Jobs mindestens nach den Dimensionen Laufzeit, Hauptspeicherbedarf und CPU-Core-Anzahl möglichst effizient im Cluster zu plazieren. (Im Hintergrund spielen noch viele andere Parameter als diese drei eine Rolle.)

Mindestens diese drei muss man also angeben, um dem Scheduler etwas zum Verteilen an die Hand zu geben.

Bevor Sie Jobs abschicken, müssen Sie ermitteln, wieviele CPUs (= Kerne) Sie am besten nutzen, wieviel Hauptspeicher Ihr wissenschaftliches Programm benötigen wird und wie lange es für die Berechnungen mindestens laufen muss.

Falls Ihr wissenschaftliches Programm und vergleichbare Probleme in Ihrer Arbeitsgruppe bereits bearbeitet werden, erkundigen Sie sich bei Ihren Kollegen nach deren Erfahrungen damit.

Falls Sie mit neuem Programm oder neuem Problem starten: bereiten Sie sich einen vergleichsweise kleinen Testfall vor (nicht mehr als 30 Minuten Laufzeit) und lassen Sie ihn auf einem der Login-Knoten mit der gewünschten Anzahl CPU-Kernen unter der Kontrolle des UNIX-„time“-Kommandos laufen:

/bin/time --format='MaxMem: %Mkb, WCT: %E' myProgram <testcase>

Danach erhalten Sie auf dem STDERR-Kanal zum Beispiel die Ausgabe

  • MaxMem: 942080kb, WCT: 1:16.00

Nach Umrechnung von „MaxMem“ in MBytes (durch 1024 dividieren) können Sie Ihren #SBATCH --mem-per-cpu=-Parameter für diesen Testlauf wie folgt errechnen:

MaxMem in MByte
--------------------- (zuzüglich Sicherheitspuffer)
# der Prozessorkerne

Ihre maximal benötigte Laufzeit ( #SBATCH -t d-hh:mm:ss im Jobscript) ist dann die obige WCT" (wiederum zzgl. Sicherheitszuschlag).

In unserem Beispiel und falls Sie 4 Prozessorkerne benutzt haben:

 942080 / 1024 / 4 =
--mem-per-cpu=230

Wenn Sie Ihren Testfall mit jeweils 2, 4, 8 und 16 Prozessorkernen laufen lassen, bekommen Sie einen groben Eindruck von der Skalierbarkeit Ihres Problems, und können die für Ihre echten Jobs nötige Laufzeit und den Hauptspeicherbedarf besser abschätzen.

In Kürze und hierarchisch dargestellt: der Lichtenberg-Cluster besteht aus

  • Rechenknoten
    einzelne, unabhängige Rechner vergleichbar einem PC/Laptop (nur mit mehr und leistungsfähigerer Hardware)
    Ein Rechenknoten besteht aus
    • zwei oder mehr CPUs (central processing units oder Prozessoren), die je in einem eigenen „socket“ stecken.
      CPUs sind die eigentlichen „programmausführenden“ Komponenten eines Knotens.
      Eine CPU besteht aus
      • mehreren Kernen, die man als separate Ausführungseinheiten innerhalb einer CPU verstehen kann.
        Je mehr Kerne, desto mehr unabhängige Prozesse bzw. Ausführungsstränge (threads) können gleichzeitig ausgeführt werden.
        Jeder Kern kann entweder von
        • einem Prozess bzw. Task (MPI)
          oder
        • einem Ausführungsstrang (thread) benutzt werden
          Solch „Multithreading“ kann z.B. mit POSIX-Threads oder heutzutage meistens OpenMP umgesetzt sein.

Eine reine MPI-Applikation würde also soviele verschiedene Prozesse (= Tasks) starten wie insgesamt an Rechenkernen (cores) zur Verfügung stehen. Diese Prozesse kommunizieren dann miteinander über MPI.

Die Prozesse eines MPI-Jobs können auch über mehrere Rechenknoten verteilt laufen, wobei die MPI-Transfers dann über Infiniband gehen.

Eine reine Multithreaded-Applikation hingegen startet nur einen Prozess, der sich dann selbst in mehrere unabhängige Ausführungsstränge aufspaltet. Jeder dieser Threads hat im Optimalfall einen einzelnen Kern zur Verfügung, so dass ein einziger Prozess mehrere Kerne gleichzeitig nutzen kann.

Die heute üblichen Programme nutzen dazu meist OpenMP (siehe $OMP_NUM_THREADS in der Dokumentation Ihres Programms).

Solche Applikationen können nicht über mehrere Knoten verteilt rechnen, dafür aber alle Kerne eines Rechenknotens im selben Programm nutzen.

Hybride Applikationen kombinieren beide Parallelisierungsverfahren: pro verfügbarem Rechenknoten starten sie z.B. nur einen Prozess (= Task), der dann wiederum die auf jedem einzelnen Knoten verfügbaren Kerne mittels Threads ausnutzt. Die Threads kommunizieren verzögerungsfrei über ihren gemeinsamen Hauptspeicher innerhalb eines Knotens, während die Prozesse wiederum mittels MPI die Knotengrenzen überwinden.

.

Wichtig in diesem Zusammenhang:

Aus historischen Gründen (aus der Ära vor den heutigen Mehrkern-CPUs) hat SLURM Parameter, die scheinbar auf CPUs zugeschnitten sind (.z.B.. --mem-per-cpu=).

Heutzutage meint das jedoch immer Kerne statt CPUs! Das mag verwirrend sein, aber die Regel ist einfach: benutzen und berechnen Sie Ihre „--mem-per-cpu“-Werte einfach so, als hieße der Parameter „--mem-per-core“.

Für sehr viele ähnliche Jobs raten wir dringend davon ab, Shellscript-Schleifen um „sbatch / squeue“ herum zu basteln. Nutzen Sie für >30..50 Jobs stattdessen einfach Job Arrays in Slurm.

Dieses Vorgehen entlastet nicht nur den Slurm-Scheduler bei seiner Arbeit, sondern Sie können auch wesentlich mehr Array-Tasks submittieren als Einzeljobs!

Beispiele für Anwendungsfälle sind:

  • dasselbe Programm, dieselben Parameter, aber wechselnde Input-Daten
  • dasselbe Programm, dieselben Input-Daten, aber jeweils mit verschiedenen Parameter-Sets
  • nicht-parallelisiertes Programm (kann nicht mehrere Cores [Multi-Threading] oder gar mehrere Nodes [MPI] auslasten), das große Mengen an separaten Input-Daten bearbeiten soll und kein Einzellauf hängt von den Ergebnissen eines anderen ab (z.B. Bildanalyse), auch High-Throughput Computing genannt

Benennen Sie die jeweils „zahlreichen“ Bestandteile mit durchgehender Numerierung: image1.png, image2.png oder paramFile1.conf, paramFile2.conf etc.

Haben Sie z.B. 3124 Sets, setzen Sie einen Job mit

#SBATCH -a 1-3124
myProgram image$SLURM_ARRAY_TASK_ID.png > image$SLURM_ARRAY_TASK_ID.png.out

auf und submittieren Sie ihn. Slurm startet jetzt einen einzigen Job mit 3124 ArrayTasks, die jeweils ihre eigene Bilddatei laden und das Ergebnis in jeweils ihre eigene Ausgabedatei schreiben.

Wenn Sie die Anzahl gleichzeitig laufender ArrayTasks limitieren müssen, nutzen Sie

#SBATCH -a 1-3124%10

Dann läßt Slurm höchstens 10 Tasks zeitgleich laufen.

Weitere Detals finden Sie in 'man sbatch' unter „--array=“.

Laufende Jobs

Prüfen Sie das Vorhandensein von allen Verzeichnissen, die Ihr Jobscript angibt, und ob Sie dort schreibberechtigt sind.

Insbesondere das Verzeichnis, das Sie mit

#SBATCH -e /path/to/error/directory/%j.err

spezifizieren, muss bereits vor Anlaufen des Jobs existieren und für Sie beschreibbar sein.

Slurm bricht Ihren Job sofort und kommentarlos ab, wenn es wegen eines fehlenden Verzeichnisses die Output- und Error-Dateien nicht schreiben kann.

Ein Konstrukt innerhalb des Jobscripts wie

#SBATCH -e /path/to/error/directory/%j.err
mkdir -p /path/to/error/directory/

ist ein „Henne und Ei“-Problem und kann daher auch nicht funktionieren: für Slurm ist der „mkdir“-Befehl ja Bestandteil des Jobs, dessen eventuelle Ausgaben (STDOUT oder STDERR) in das noch nicht existierende Verzeichnis geschrieben werden müßten.

Stellen Sie sicher, dass alle relevanten Module in Ihrem Jobscript geladen werden.

Sie können die nötigen Module zwar nach dem Login direkt auf dem Loginknoten laden, weil diese dann von „sbatch myJobScript“ an den Job „vererbt“ werden, aber das ist nicht zuverlässig.
Stattdessen macht es Ihre Jobs von den in der Login-Umgebung geladenen Modulen abhängig.

Darum empfehlen wir, jedes Jobscript mit

module purge
module load <each and every relevant module>

zu beginnen, um genau die (und nur die) Module zu laden, die Ihr wissenschaftliches Programm benötigt.

Das erleichtert auch die spätere Reproduzierbarkeit Ihrer Jobs, ganz unabhängig von dem Modulset, was Sie damals in Ihrer Login-Session geladen haben.

Dieses Verhalten kann auftreten, wenn der Job mehrfache verschachtelte Aufrufe von srun (oder mpirun) enthält. Der zweite („innere“) Aufruf versucht dann, dieselben Ressourcen zu allozieren wie der erste („äußere“), und das kann nicht gehen.

Wenn in Ihrem Jobscript

srun /path/to/myScientificProgram

steht, prüfen Sie, ob „/path/to/myScientificProgram“ nicht vielleicht ein Script ist, das selbst wiederum srun (oder mpirun) aufruft.

In diesem Fall entfernen Sie einfach das srun vor /path/to/myScientificProgram.

Beispiel-Fehler:

srun: Job XXX step creation temporarily disabled, retrying
srun: error: Unable to create step for job XXX: Job/step already completing or completed
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP XXX.0 ON hpb0560 CANCELLED AT 2020-01-08T14:53:33 DUE TO TIME LIMIT ***
slurmstepd: error: *** JOB XXX ON hpb0560 CANCELLED AT 2020-01-08T14:53:33 DUE TO TIME LIMIT ***

Slurm kann nicht erkennen, welches der Kommandos in einem Job (script) wirklich „wichtig“ ist. Der einzige Mechanismus zur Feststellung von Erfolg oder Fehler ist der exit code Ihres Jobscripts, nicht der „echte“ Verlauf Ihres wissenschaftlichen Programms.

Programme, die sich an gängige Programmierkonventionen halten, beenden sich mit einem exit code von 0, wenn alles geklappt hat, und >0 im Fehlerfall.

Im folgenden Beispiel

#!/bin/bash
#SBATCH …
myScientificProgram …

ist das zuletzt ausgeführte Kommando wirklich das wissenschaftliche Programm, und damit endet das gesamte Jobscript wie gewünscht auch mit dessen realem exit code. Slurm wird den Job nun als COMPLETED behandeln, wenn „myScientificProgram“ mit 0 geendet hat, und als FAILED, falls nicht.

Fügt man nun aber irgendwelche anderen Kommandos (zum Aufräumen oder Resultate-Kopieren) nach „myScientificProgram“ ein, überschreiben diese den exit code des eigentlichen Programms:

#!/bin/bash
#SBATCH …
myScientificProgram …
cp resultfile $HOME/jobresults/

Jetzt bestimmt das Ergebnis des „cp“-Befehls den exit code des gesamten Jobscripts, weil es sein letztes Kommando ist. Klappt der Kopierbefehl, wird Slurm den Job als COMPLETED bezeichnen, obwohl „myScientificProgram“ eine Zeile vorher komplett fehlgeschlagen sein könnte.

Um das zu vermeiden (und trotzdem nach der eigentlichen wiss. Rechnung noch Kommandos auszuführen), muss man den „wichtigen“ exit code vor den nächsten Kommandos zwischenspeichern:

#!/bin/bash
#SBATCH …
myScientificProgram …
EXITCODE=$?
cp resultfile $HOME/jobresults/
/any/other/job/closure/cleanup/commands …
echo Job finished at $(/bin/date +%FT%R)
exit $EXITCODE

Jetzt wird der exit code von „myScientificProgram“ in der Variablen $EXITCODE zwischengespeichert. Trotz der darauffolgenden Kommandos kann man das Jobscript via exit-Befehl nun mit dem „echten“, wichtigen exit code der eigentlichen wiss. Berechnung beenden.

Somit erhält Slurm jetzt diesen exit code der wiss. Berechnung (statt den des zufällig letzten Kommandos im jobscript) und wird nur noch solche Jobs als COMPLETED betrachten, bei denen „myScientificProgram“ fehlerfrei durchgelaufen ist.

Nur während der Laufzeit eines Ihrer Jobs.

Generell ist der direkte Login auf Rechenknoten nicht möglich.

Die einzige Ausnahme sind die Knoten, auf denen gerade einer Ihrer Jobs läuft – vom Login-Node aus (nicht aus dem Internet) können Sie sich dann auf diese Knoten weiterverbinden (siehe die Ausgabe von squeue unter „NODELIST“).

Das dient dazu, das Verhalten Ihrer Jobs direkt auf den ausführenden Knoten mittels top oder ähnlichen Tools zu beobachten.

Im Fall von MPI-Jobs, die auf mehreren Knoten laufen, müssen Sie die NODELIST vom squeue in einzelne Hostnamen zerlegen. Beispielsweise sind hpa0[301,307,412-413] folgende Knoten -

hpa0301
hpa0307
hpa0412
hpa0413

Auf jeden dieser Knoten können Sie sich (vom Loginknoten aus) mittels „ssh hpa0…“ weiterverbinden, solange Ihr Job darauf läuft.

Sollten Sie noch eingeloggt sein, wenn Ihr Job endet, wird auch Ihre ssh-Sitzung zum Rechenknoten beendet und Sie sind wieder auf dem Loginknoten.

Wartende Jobs

Die von Slurm-Kommandos wie „squeue“ oder „sprio“ angezeigten Prioritätswerte sind immer relativ zueinander und relativ zur momentanen Last auf dem Cluster zu verstehen. Es gibt keinen „Absolut“- bzw. „Schwellwert“ der Priorität, ab der Jobs unabdingbar anlaufen.

So kann in Phasen geringer Last auf dem Cluster bereits ein kleiner Prioritätswert genügen, um Jobs (auf den freien Ressourcen) umgehend anlaufen zu lassen. Zu Zeiten hoher Last und gar keiner freien Ressourcen kann hingegen selbst ein viel höherer Prioritätswert nicht verhindern, dass die Jobs lange warten müssen.

Da die Standardlaufzeit von Jobs 24h beträgt, müssen in Phasen hoher Last auch mindestens 24 Stunden Wartezeit einkalkuliert werden…

Sie können sich mit dem Kommando „squeue --start“ vom Scheduler eine Schätzung anzeigen lassen, wann ungefähr Ihre Jobs anlaufen werden.

Die Ausgabe „N/A“ ist dabei völlig normal, denn der Scheduler betrachtet nicht bei jedem Scheduling-Durchlauf jeden Job. So kann es eine Weile dauern, bis der Scheduler auch nur zu dieser „Schätzung“ für Ihre wartenden Jobs gelangt.

Generell hängt die Wartezeit eines Jobs nicht nur von der Priorität Ihrer Jobs ab, sondern auch von der momentanen Auslastung des Clusters. Darum läßt sich ganz allgemein keine 1:1-Beziehung zwischen Priorität und Wartezeit errechnen.

Auf dem Lichtenberg-HLR läuft der Scheduler im „Fair Share“-Modus: je mehr Rechenzeit Sie verbrauchen (insbesondere über Ihr monatliches Projektkontingent hinaus), desto geringer wird Ihre Priorität.

Diese Reduktion Ihrer Priorität hat aber eine Halbwertszeit von ca. 14 Tagen, so dass sich Ihr Wert über die Zeit hinweg „erholt“.

Am besten verbrauchen Sie Ihre Rechenzeit gleichmäßig über die gesamte Projektlaufzeit (siehe 'csreport'), dann sinkt Ihre Priorität auch nur moderat ab.

Bei einer geplanten Auszeit teilen wir dem Batchsystem vorher mit, wann die Auszeit beginnt. Aufgrund Ihrer Angaben, wie lange Ihre jeweiligen Jobs laufen werden (#SBATCH -t d-hh:mm:ss im Jobscript), entscheidet der Batch-Scheduler, ob Ihr Job noch sicher vor der Auszeit beendet werden kann. In diesem Fall läßt er ihn noch anlaufen.

Wartende Jobs (Status „PENDING“), die nicht mehr vor der Auszeit beendet werden können, laufen also auch gar nicht mehr an.

Alle wartenden Jobs in allen Queues (Status „PENDING“) bleiben über Auszeiten und Ausfälle hinweg erhalten, und werden wie gewohnt prioritätsgesteuert nach der Auszeit anlaufen.

Sonstiges

Wie die Rechenknoten sind auch unsere Login-Knoten nicht mit herkömmlichen Methoden auf Festplatten installiert. Stattdessen holen sie sich bei jedem Neustart (und somit auch nach jeder Auszeit) ein Betriebssystem-Abbild über das Netzwerk und entpacken es in ihrem Hauptspeicher.

Damit haben sie nach jedem Neustart einen genau definierten (und getesteten) Zustand.

Da „cron“- und „at“Aufträge im Systembereich gespeichert werden und dieser nach einem Neustart zurückgesetzt ist, sind Cron-Einträge nicht permanent und darum nicht verlässlich.

Damit Nutzer nicht doch welche anlegen (und sich auf deren Funktion z.B. zum Backup verlassen), haben wir „cron“ und „at“ lieber ganz abgeschaltet.

Seit Juni 2020 ist ein neuer Synchronisierungsmechanismus in Kraft: sowie Sie Ihr TUID-Passwort im IDM-System der TU Darmstadt ändern, wird auch Ihr Login-Passwort zum Lichtenberg-Cluster damit synchronisiert.

Bei neuen Nutzer_innen ist dies von Anfang an der Fall, also schon der erste Login zum Lichtenberg erfolgt mit dem TUID-Passwort.

Bei bestehenden Benutzer_innen gilt vorerst unverändert deren altes HLR-Passwort (das, was zuletzt auf dem „HLR“-Tab im alten „ANDO“-Portal gesetzt wurde).

Bei der ersten/nächsten Änderung des TUID-Passworts über das IDM-Portal wird auch das alte HLR-Passwort durch das neue TUID-Passwort überschrieben.

All das gilt ebenso für Gast-TUIDs.

cg81tadi (Griebel, Christian) - directory permissions with setGID and sticky bits
Verzeichnisrechte mit setGID und sticky-Bit

Wir realisieren die Projekt- und Gruppen-Quota in diesen Verzeichnissen über die jeweiligen UNIX-Gruppen da_p<ProjID> bzw. da_<Institutskürzel> (im folgenden als da_XXX versinnbildlicht).

Dateien (und Verzeichnisse), die nicht diesen Gruppen gehören, werden dem Anlegenden persönlich zugeordnet. Da Personen/TUIDs auf diesen Verzeichnissen jedoch eine sehr geringe Quota haben, führen falsch zugeordnete Dateien schnell zu „quota exceeded“-Fehlern.

Verzeichnisse und Dateien irgendwo unterhalb von /work/projects/ bzw. /work/groups/:

  • müssen der entsprechenden Gruppe da_XXX gehören (und nicht Ihrer TUID-Gruppe)
  • Verzeichnisse müssen die Rechte drwxrws--- haben
    Das „sticky“-Bit auf der Gruppenebene sorgt dafür, dass neu angelegte Dateien in diesem Vz. automatisch die Gruppenzugehörigkeit des Elternverzeichnisses erben (und nicht die des anlegenden Benutzers)

Falsch: drwx------ 35 tuid tuid 8192 Jun 17 23:19 /work/groups/…/myDir

Richtig: drwxrws--- 35 tuid da_XXX 8192 Jun 17 23:19 /work/groups/…/myDir

Lösung:

Wechseln Sie in das Elternverzeichnis, unterhalb dessen das Problem-Verzeichnis liegt, und prüfen sie dessen Zugriffsrechte. Stimmen sie nicht und gehört das Verzeichnis Ihnen:

chgrp -R da_<XXX> myDir

chmod 3770 myDir

Stimmen sie nicht, aber das Verzeichnis gehört nicht Ihnen, bitten Sie den Inhaber, diese Kommandos auszuführen.

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.

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.