Tipps und Tricks

Automatisches Laden beim Login

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.

module load im Job-Script definieren

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.

Eigene Modul-„collections“ definieren

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

Archive entpacken im /work/scratch – Achtung automatische Löschung

Das Entpacken von Archiven (z.B. *.zip, *.tar etc.) verursacht oft das Beibehalten der darin enthaltenden „modification time“ aller Dateien. Sind die entpackten 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 Archive-Programme oft eine Option, um die „modification time“ nicht zu übernehmen, sondern für alle entpackten Dateien einen neuen 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.

Hinweis: Ab dem 18.4.2017 wird die automatische Löschregel für den Scratch-Bereich auf die „creation time“ umgestellt! Die Aktualisierung der „modification time“ ist danach nicht mehr nötig bzw. hat danach keine Wirkung mehr zur Verlängerung der Speicherzeit von Dateien. Mit der Umstellung auf „creation time“ wird zukünftig das tatsächliche Anlegen einer Datei als Maß für das Alter verwendet – und nach einem Datei-Alter von mehr als 8 Wochen automatisch gelöscht.

Fehlender Slurm-Support in MPI-Anwendungen

Viele Anwendungen haben Probleme die richtige Anzahl Rechenkerne im Batchsystem zu nutzen. Das kann beispielsweise an mangelnder Slurm-Unterstützung liegen. Die meisten dieser problematischen Anwendungen bringen ihre eigene 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>“:

srun hostname > hostfile.$SLURM_JOB_ID
mpirun  -n 64  -hostfile hostfile.$SLURM_JOB_ID  <MPI-Programm>

Die erste Zeile (oben) erzeugt das Hostfile, die zweite Zeile übergibt dem MPI zusätzlich die Anzahl der zu verwendenden Rechenkerne (hier 64) und den Namen des Hostfiles.

Abschließende Job Details

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.

seff <JobID>

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

sacct -l -j <JobID>
tuda-seff <JobID>

Gültigkeitsdauer des eigenen Accounts

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.

Fileübertragung zum und vom Lichtenberg HPC

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.

Wir empfehlen folgende Verfahren:

Einmalige Übertragungen: scp

So wie man sich per ssh auf den Loginknoten anmeldet, können Dateien und Verzeichnisse mit dem SSH-Werkzeug scp ü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).

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:

tuid@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 drastisch 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:

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

Details: man rsync,

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

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

Nicht verfügbar auf dem Lichtenberg:

FTP(S), sFTP, HTTP(S), rcp und andere ältere, (Klartext-) Protokolle.