Tipps und Tricks

Unsere Mailingliste [HPC-Nutzer] ist der schnellste Weg, Informationen über Ausfälle oder Störungen zu erhalten, und kann am einfachsten per Mailkommando abonniert bzw. abbestellt werden.

Abonnieren

Senden Sie von der Mailadresse aus, mit der Sie unsere News empfangen wollen, einfach eine Mail mit „subscribe“ im Betreff und/oder im Mailtext an hpc-nutzer-request@lists.tu-….

Kurz darauf erhalten Sie eine „opt-in“-Mail zur nochmaligen Bestätigung, dass wirklich Sie die Abo-Mail abgesandt haben. Nach deren Bestätigung erhalten Sie alle kommenden HLR-/HPC-bezogenen Nachrichten.

Abbestellen

Senden Sie von der Mailadresse aus, mit der Sie unsere News zur Zeit empfangen, einfach eine Mail mit „unsubscribe“ im Betreff und/oder im Mailtext an hpc-nutzer-request@lists.tu-….

Kurz darauf erhalten Sie eine Bestätigungsmail der Beendigung Ihres Abonnements, und ab dann keine HLR-/HPC-bezogenen Nachrichten mehr per Mail.

Das Ablaufdatum des eigenen Benutzeraccounts kann mit dem Script /shared/bin/account_expire abgefragt werden.

Die Laufzeit Ihres Benutzeraccounts ist unabhängig von der Laufzeit bzw. Gültigkeit aller Projekte, denen Sie zugeordnet sind.

Um Ihre aktuellen Mitgliedschaften in (aktiven) HLR-Projekten zu sehen, können Sie

• den Befehl „cat ~/.project“ ausführen (wird nächtlich aktualisiert)
• den Befehl „member“ ohne jeden Parameter ausführen (unmittelbare Anzeige des Ist-Zustands)

Ablauffristen

Da Projekte mehrere Nutzer/Mitglieder haben können, und man andererseits Mitglied in mehreren Projekten sein kann, besteht zwischen den Gültigkeitsfristen von HLR-Nutzerzugängen und HLR-Projekten keinerlei Zusammenhang – beide laufen unabhängig voneinander (aus). Ebenso umfasst die Verlängerung des einen nicht die Verlängerung des jeweils anderen.

Falls Sie bestimmte Module immer und automatisch beim Einloggen aktivieren wollen, editieren Sie Ihre $HOME/.bashrc_profile, und fügen am Ende folgende Zeilen hinzu:

if [ -n „${PS1}“ ] ; then
 # interactive shell, do output only after that check:
 module load <module1>/<v1> <module2>/<v2> …
fi

Beim nächsten Anmelden sind die angegebenen Module geladen, sobald der Shell-Prompt % erscheint.

Um es Ihnen einfach zu machen, übernimmt Slurm beim Submittieren standardmäßig die Umgebung (environment) und die geladenen Module aus der (Login-) Sitzung, aus der Sie den Job abschicken.

Für die Reproduzierbarkeit einer Job-Umgebung ist es jedoch sinnvoll, ein Jobscript mit module purge zu beginnen und dann nur alle für den Job notwendigen Module explizit mit module load zu laden. Nur so ist sichergestellt, dass beim Programmlauf wirklich nur die gewünschten bzw. notwendigen Module (in ihrer richtigen Version) verwendet werden.

Das gilt insbesondere, wenn man beispielsweise mit module initadd bestimmte Module automatisch in der eigenen ~/.bashrc lädt, weil man sie wieder und wieder in jeder (Login-) Sitzung benötigt.

Wenn ein optimales Set an Modulen gefunden ist, das für eine ganze Klasse von Jobs passend ist, kann man daraus eine sog. „collection“ machen, die dann in allen Jobscripts mit einem einzigen Befehl geladen werden kann.

Laden Sie dazu genau Ihre gewünschten Module mittels „module load mX mY mZ …“ (ggf. mit „… mX/versionX mY/versionY mZ/versionZ …“), und führen Sie dann „module save <myCollectionName>“ aus.

In späteren Jobscripts können Sie diese „collection“ dann mittels

module purge
module restore <myCollectionName>

sauber wiederherstellen und aktivieren.

LMod legt jede Ihrer „collections“ in einer Datei namens $HOME/.lmod.d/<myCollectionName> ab, wo Sie sie auch inspizieren können.

Eine Liste all Ihrer „collections“ erhalten Sie mit „module savelist“.

Das Entpacken von Archiven (z.B. *.zip, *.tar etc.) verursacht oft das Beibehalten der darin enthaltenden „modification time“ aller Dateien.

Entpacken Sie ein Archiv nach /work/scratch/<TU-ID> und sind die extrahierten Dateien älter als 8 Wochen, können sie durch die automatischen Lösch-Regeln des Scratch-Bereiches bereits einen Tag später verloren gehen.

Es gibt für die verschiedenen Archiv-Programme oft eine Option, um die „modification time“ nicht zu übernehmen, sondern für alle entpackten Dateien einen aktuellen Zeitstempel zu generieren. Für tar hilft beispielsweise die Option -m. Alternativ kann man für alle gerade entpackten Dateien mit dem Kommando „touch“ nachträglich einen neuen Zeitstempel generieren.

Viele Anwendungen haben Probleme damit, die richtige Anzahl Rechenkerne im Batchsystem zu nutzen, beispielsweise wegen mangelnder Slurm-Unterstützung. Die meisten dieser problematischen Anwendungen bringen ihre eigene (built-in) MPI-Version mit und müssen daher explizit mit der richtigen Anzahl Rechenkerne und auch dem so genannten Hostfile unterstützt werden.

Als erstes muss dazu ein aktuelles Hostfile generiert werden. Die nachfolgenden Zeilen ersetzen den sonst üblichen Aufruf „mpirun <MPI-Programm>“:

Python „conda“-Umgebungen können im Zusammenspiel mit Python-Modulen unseres Modulsystems zu Problemen führen.

Daher empfehlen wir, besser Python „virtual environments“ zu nutzen, wenn Sie Erweiterungen (python packages) hinzuladen möchten, die nicht bereits im zentralen Modulsystem vorhanden sind.

Um Ihr neues „vEnv“ namens „myenv“ vorzubereiten (einmalig notwendig):

Natürlich können Sie Ihrem vEnv sprechendere Namen als „myenv“ geben, und Sie können es statt in Ihr $HOME auch in Projekt- (oder Gruppen-) Verzeichnisse installieren, um es Ihrem Team zur Verfügung zu stellen.

Nachdem Sie Ihr „myenv“ (einmalig auf dem Loginknoten) solcherart eingerichtet haben, ist es in Batch-Jobs nutzbar:

Mit dem nachfolgenden Kommando kann man sich nach Beendigung eines Jobs mit der <JobID> noch Details über die Ressourcen-Ausnutzung (CPU, Memory etc.) ausgeben lassen.

Eine ausführlichere Alternative mit noch mehr Details erhält man auch mit dem nachfolgenden Kommando.

Vor den Rechnungen auf dem Lichtenberg müssen Ihre Daten auf die Filesysteme des Lichtenberg-Rechners und danach Ihre Resultate wieder zurück übertragen werden.

Benutzen Sie hierfür ebenfalls die Loginknoten , denn diese haben leistungsfähige Netzwerkanschlüsse auch in das Campus-Netz der TU (wir betreiben keine speziellen input/output-Knoten).

Wir empfehlen folgende Verfahren:

Einmalige Übertragungen: scp (oder sftp)

So wie man sich per ssh auf den Loginknoten anmeldet, können Dateien und Verzeichnisse mit dem SSH-Werkzeug scp (oder der FTP-Entsprechung sftp) übertragen werden.

Bei großen Text-/ASCII-Dateien wird die im SSH-Protokoll enthaltene, optionale Kompression (-C) empfohlen, die verlustfrei & transparent beim Transfer dafür sorgt, die Netzwerk-Bandbreite zu schonen und die den Transfer beträchtlich beschleunigen kann.
Lassen Sie die Kompression weg, wenn bereits vorkomprimierte Daten wie JPG-Bilder oder Videos in modernen Containerformaten (mp4, OGG) übertragen werden sollen.

Beispiel:

tu-id@logc0004:~ $ scp -Cpr myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir

Details: man scp

Ausfallsicherheit: keine (nach Abbrüchen überträgt scp alles neu).

Wiederholte Transfers: rsync

Einige Fälle wie z.B. wiederkehrende Transfers lassen sich mit scp nur unzureichend abbilden.

Beispiele: „zur Analyse mit grafischen Werkzeugen brauche ich die Berechnungsergebnisse des HLR umgehend auf meiner lokalen Workstation-Platte“, oder „Die Rohdaten aus meinen lokalen Experimenten müssen umgehend auf den HLR zur Auswertung“.

Sowie man ein Verzeichnis auf dem Lichtenberg zu einem lokalen bei sich im Institut weitgehend synchron halten möchte, wäre wiederholtes scp ineffizient, da es keine Ahnung von „Änderungen“ hat und blindlings alles immer wieder überträgt (auch das, was schon im Ziel vorhanden ist).

Hier kann rsync helfen. Wie scp ein Kommandozeilen-Werkzeug zur Dateiübertragung zwischen (entfernter) Quelle „SRC“ und (entfernter) „DEST“ination, kann es anders als scp aber erkennen, welche Dateien in „SRC“ geändert wurden und überträgt nur diese. Kleine Dateien werden dabei im Ganzen (neu) übertragen, bei großen analysiert rsync die Änderungen (gesichert durch Prüfsummen) und überträgt nur die geänderten Blöcke.

Während der erste Transfer eines gefüllten Verzeichnisbaums in sein noch leeres Ziel kaum schneller sein wird als mit „scp -Cr“, laufen spätere Synchronisierungen deutlich schneller, weil nur noch geänderte (Teile von) Dateien übertragen werden (unveränderte Dateien sind ja schon da).

Zusammengefaßt: ungeänderte Datein gehen ab dem zweiten Transfer gar nicht mehr über die Leitung, geänderte kleine im Ganzen und bei geänderten großen Dateien überträgt rsync nur die Änderungen (Delta).

Beispiel:

tu-id@logc0004:~ $ rsync -aH myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir

Details: man rsync

Ausfallsicherheit: teilweise (nach Abbrüchen überträgt rsync nur das, was im Ziel noch fehlt).

Achtung: sowohl scp als auch rsync sind nur „Einbahnstraßen“! Wenn sich zwischen zwei Transfers eine Datei in „DEST“ ändert, wird sie beim nächsten Transfer von ihrer (alten) Version in „SRC“ überschrieben.

Nicht verfügbar auf dem Lichtenberg:

HTTP(S), SMB (CIFS), rcp und andere ältere, (Klartext-) Protokolle.