Rechnen auf Palma

Kompilieren von Programmen

Das Modul-Konzept

Umgebungsvariablen (z.B. PATH, LD_LIBRARY_PATH) für Compiler und Bibliotheken werden über module-Befehle definiert:

Befehl (Kurz- und Langform)	Bedeutung
module av[ailable]	Listet alle verfügbaren Module auf
module li[st]	Zeigt alle in der aktuellen Umgebung geladenen Module.
module show modulname	Listet die Änderungen auf, die ein Modul an der Umgebung bewirkt.
module add modul1 modul2 ...	Fügt Module der aktuellen Umgebung hinzu.
module rm modul1 modul2 ...	Entfernt Module aus der aktuellen Umgebung.
module purge	Löscht alle aktivierten Module aus der Umgebung.

Erklärung zur Benennung

Das Schema zur Benennung der Module besteht meistens aus Kategorie/Compiler/Version Dabei bezeichnet Kategorie grob, mit welchem Programm oder welcher Bibliothek man es zu tun hat, Compiler, mit welchem Compiler das Programm übersetzt wurde und Version steht für die genaue Versionsnummer.

Wird keine Versionsnummer beim laden des Moduls angegeben, so wird immer die höchste Versionsnummer gewählt. Das kann gemacht werden, wenn es nicht auf die spezifische Version ankommt. Ansonsten ist es empfehlenswert, eine feste Versionsnummer anzugeben, so dass auch bei der Installation von neuen Versionen der entsprechenden Bibliothek auf Palma keine unerwarteten Ereignisse beim kompilieren des eigenen Programms auftreten.

Welche Module sollten normalerweise geladen werden

Als Standard Compiler kommt der Intel-Compiler zum Einsatz:

module add intel/cc/11.1.059

Auf Palma ist MPI von Intel installiert. Um es nutzen zu können, muss ebenfalls ein Modul geladen werden.

module add mpi/intel/4.0.0.028

Die wichtigsten Kompileraufrufe lauten dann analog zum seriellen Intelcompiler mpiicc, mpiicpc, mpiifort usw.

Beispiel: Übersetzen eines Programms mit der FFTW2 mit dem Modulkonzept

module add intel/cc/11.1.059
module add mpi/intel/4.0.0.028
module add fftw/2.1.5
mpiicc -I ${FFTW2_INCLUDE_DIR} -o Programm mpifftw2d.c -g -O3 -L${FFTW2_LIB_DIR} -lsrfftw_mpi -lsfftw_mpi -lsrfftw -lsfftw -lm

Zur Erklärung: Die Module shared und path müssen natürlich schon geladen sein. Durch das Modul fftw/2.1.5 werden laut "module show fftw/2.1.5" die Umgebungsvariablen FFTW2_INCLUDE_DIR und FFTW2_LIB_DIR gesetzt, die dann beim Kompilieren (auch im makefile) verwendet werden können.

Makefiles

Für komplexere Projekte bietet es sich an, makefiles für das kompilieren von Programmen zu nutzen. Dadurch müssen die Befehle für das Kompilieren nicht mehr jedes mal eingegeben werden. Eine Übersicht, wie makefiles aufgebaut sind, findet man beispielsweise hier: http://www.ijon.de/comp/tutorials/makefile.html

Submittieren von Jobs

Für die Verteilung von Rechenjobs auf dem Cluster sorgen das Batchsystem TORQUE sowie der Scheduler Maui. Ein manuelles Starten von längeren Programmläufen auf den Rechenknoten oder auf PALMA am Batchsytem vorbei ist nicht erlaubt. Solche "streunenden" Prozesse werden ohne Vorwarnung vom Administrator beendet. Grundsätzlich sollten Batch-Jobs nur vom Dialogserver palma1 aus abgeschickt werden.

Erstellen des submit-files

Beispiel für ein submit-file eines MPI-Jobs:

#PBS -o output.dat
#PBS -l walltime=01:00:00,nodes=4:westmere:ppn=12
#PBS -A Projektname
#PBS -M Nutzername@uni-muenster.de
#PBS -m ae
#PBS -q default
#PBS -N Jobname
#PBS -j oe
cd $PBS_O_WORKDIR
mpdboot --rsh=ssh -n 4 -f $PBS_NODEFILE  -v
mpirun --rsh=ssh -machinefile $PBS_NODEFILE -np 32 ./Programmname

Hier wird ein MPI-Job gestartet, der mit insgesamt 32 Prozessen läuft. Dazu werden 4 westmere-Knoten mit je 12 Prozessorkernen angefordert.

Weitere Angaben:

• Projektname: Muss unbedingt durch das eigene Projekt erstetzt werden, ansonsten startet der Job nicht.
• Nutzername: Durch eigene Kennung ersetzen, damit Emails korrekt zugestellt werden können
• Jobverzeichnis: Durch Pfad, in dem das Programm liegt, ersetzen.
• Programmname: Hier den Namen der auszuführenden Datei eintragen.
• walltime: Die nötige Zeit, die das Programm läuft, angeben. Nach Ablauf der Zeit wird der Job abgebrochen. Maximal 48 Stunden sind möglich.

Benötigt das Programm kein MPI, kann die Datei entsprechend vereinfacht werden.

Beispiel für ein submit-file eines openmp Jobs:

#PBS -o output.dat
#PBS -l walltime=01:00:00,nodes=1:westmere:ppn=12
#PBS -A Projektname
#PBS -M Nutzername@uni-muenster.de
#PBS -m ae
#PBS -q default
#PBS -N Jobname
#PBS -j oe
cd $HOME/Jobverzeichnis
./Programmname

Abschicken des Jobs/Verwaltung der Warteschlange

Ein Job wird gestartet, indem die oben erzeugte submit-Datei mittels

 qsub submit.cmd 

abgeschickt wird, wobei submit.cmd der Name der submit-Datei ist.

Weitere Befehle:

• qstat: Zeigt die derzeitige Warteschlange an
• qstat -a: Selbiges, nur mit Anzahl der angeforderten Knoten
• qstat -n: Alle Knoten, die den Jobs zugeordnet sind, werden aufgeschlüsselt
• qdel Jobnummer: Löscht Jobs aus der Warteschlange
• showbf: Zeigt die Anzahl der freien Prozessorkerne
• showres: Zeigt an, wann ein Job gestartet wird

Die Auswahl der Rechenknoten

Mit der Option -l legt man die Ressourcenanforderungen für den Batch-Job fest. Bei der Festlegung der Anzahl und Art der Nodes ist zu beachten, dass die Rechenknoten des Systems zur Unterscheidung mit den Eigenschaften "nehalem" und "westmere" gekennzeichnet sind. Außerdem gibt es pro Node mehrere CPU-Kerne, so dass die Angabe nodes zwei unterschiedliche Bedeutungen haben kann. Die folgende Tabelle soll verdeutlichen, wie sich die Angabe nodes auf die Auswahl der Rechenknoten auswirkt:

Angabe im Batch-Job	Auswahl der Rechenknoten
-l nodes=10:westmere:ppn=12	10 Westmere Knoten mit je 12 Kernen.
-l nodes=2:himem:ppn=12	2 Westmere himem Knoten (mit 48 GB Hauptspeicher pro Knoten)
-l nodes=1:ppn=8	8 Prozessorkerne eines Westmere oder Nehalem Knotens (nicht empfohlen)
-l nodes=1:nehalem:ppn=1	1 Prozessorkern eines Nehalem Knotens (empfohlen für serielle Jobs)

Generell sollten, um die Fragmentierung der Jobs auf dem Cluster klein zu halten, serielle Jobs auf den Nehalem Knoten laufen, parallele auf den Westmere (bzw. himem) Knoten.

Zusätzlich zu der Anzahl der Knoten kann auch Einfluss auf bestimme Ressourcen genommen werden. Zu beeinflussen sind:

• Walltime: Wie lange soll der Job rechnen? In Stunden, je nach queue maximal 48, bzw. 160 Stunden
• Hauptspeicher: Wie viel Speicher ist notwendig? Ist mehr als 2 GB Hauptspeicher pro Kern notwendig, sollten unbedingt die himem-Knoten verwendet werden (siehe Beispiel unten), da ansonsten geswappt wird, was die Rechnung stark verlangsamt.

Beispiel (24 Stunden auf 24 Westmere-Kernen mit jeweils 4 GB Hauptspeicher):

#PBS -l walltime=24:00:00,nodes=2:himem:ppn=12

Wichtig: Nur wenn ein vollständiger Knoten angefordert wird, sorgt ein Skript dafür, dass vorher auf dem Knoten aufgeräumt wird und eventuell noch vorhandene Reste alter Jobs entfernt werden. Jobanforderungen sollten also möglichst so ausgelegt werden, dass komplette Knoten verwendet werden.

Um möglichst wenig Kollisionen zwischen seriellen und parallelen Rechnungen zu verursachen werden alle Nutzer gebeten, serielle Rechnungen auf den Nehalem-Knoten zu starten und parallele auf den Westmere-Knoten.

Die verschiedenen Warteschlangen

Es gibt verschiedene Warteschlangen, um den unterschiedlichen Bedingungen der Nutzer gerecht zu werden:

• default: maximal 48 Stunden Rechenzeit, alle Knoten mit Ausnahme von palma060-palma065
• long: maximal 160 Stunden Rechenzeit, es können maximal 18 Knoten angefordert werden
• mescashort: umfasst die Knoten palma060-palma063 und palma065, die mit 256 GB RAM und 32 CPU-Kernen ausgestattet sind; maximal 4 Jobs pro Nutzer werden gleichzeitig ausgeführt, die Rechenzeit ist auf 48 Stunden beschränkt
• mescalong: wie mescashort, es werden aber maximal 2 Jobs pro Benutzer ausgeführt, die maximale Rechenzeit beträgt 160 Stunden
• mescatest: Höher priorisierte Testqueue, um Jobs auf den largesmp-Knoten zu testen, die Rechenzeit ist auf 1 Stunde beschränkt
• mescabig: Besteht nur aus palma064, der mit 512 GB Hauptspeicher und 40 CPU Kernen ausgestattet ist. Maximale Walltime ist 160 Stunden

Globale Beschränkungen:

• Es können maximal 132.710.400 Sekunden Rechenzeit gleichzeitig angefordert werden. Dies entspricht z.B. 48 Stunden Walltime auf 64 Westmereknoten. Soll auf mehr Knoten gerechnet werden, muss die Walltime entsprechend niedriger gewählt werden. Natürlich können mehrere Jobs in die Warteschlange gestellt werden, die diese Bedingung maximal ausnutzen. Diese werden dann nacheinander abgearbeitet.

Abschicken von Massenjobs

Wenn nicht nur ein Job, sondern eine ganze Reihe von Jobs gerechnet werden soll, die sich nur wenig unterscheiden, kann dies auch über das Batchsystem gesteuert werden.

Dazu muss im Submitskript die Zeile

#PBS -t 1-5

eingefügt werden, damit fünf gleichartige Rechnungen gestartet werden. Zur Unterscheidung kann im Submitskript mit der Variable $PBS_ARRAYID gearbeitet werden, die in diesem Beispiel alle Werte zwischen 1 und 5 annimmt. Damit können beispielsweise verschiedene Unterverzeichnisse erstellt werden:

DIRNAME=$(printf "run%d" "$PBS_ARRAYID")
mkdir $DIRNAME
cd $DIRNAME
cp $HOME/codes/Programmname .
./Programmname

Durch dieses Vorgehen vereinfacht sich das Abschicken und die Verwaltung einer größeren Anzahl von Rechnungen. Die per qstat ausgegebenen Job IDs folgen dabei dem Schema JobID-t, d.h. alle Jobs können gleichzeitig mittels qdel JobID beendet werden. Trotzdem können auch noch einzelne Jobs beeinflusst werden: qalter JobID-5

Jobs in Abhängigkeit von anderen Jobs starten

Soll eine Rechnung erst dann gestartet werden, wenn eine andere beendet wurde (beispielsweise der Auswertejob nach der eigentlichen Berechnung), kann der Schalter -W beim qsub Kommando verwendet werden.

depend=dependency_list (Abhängigkeiten zwischen einzelnen Jobs festlegen)
Beispiel: -W 'depend=afterok:4517'

Job kann nur nach erfolgreichem Beenden von Job Nr. 4517 gestartet werden

Übersicht über laufende Jobs

Es gibt verschiedene Möglichkeiten, wie die Nutzer sich eine Übersicht über den Status des Clusters und die laufenden Jobs verschaffen können:

• qstat -a: Zeigt die Warteschlange inkl. aller laufenden und wartenden Jobs an (diverse andere Optionen mit man qstat
• pbstop: Grafische Übersicht auf der Kommandozeile über laufende Jobs
• myJAM: Webinterface, bei dem der Zustand des Clusters unter "Rack View" grafisch zu sehen ist
• Ganglia: Komplexes Webinterface mit hohem Informationsgehalt. Zeigt unter anderem die Auslastung der einzelnen Knoten zeitlich Aufgelöst an.

Die scratch Partition

Unter /scratch/tmp befinden sich 180 TB Speicherplatz, der genutzt werden kann, um die in den Programmen generierten Daten zu speichern. Diese sollten aus Platz- und Geschwindigkeitsgründen nicht im Homeverzeichnis gespeichert werden. Als Dateisystem kommt lustre zum Einsatz, das einige Besonderheiten besitzt. Als paralleles Dateisystem ist lustre dafür ausgelegt, wenige große Dateien zu speichern. Deswegen ist es nicht zu empfehlen, sehr viele kleine Dateien abzulegen. Die Performance wird dabei sehr stark einbrechen.

Bitte ein Unterverzeichnis mit dem eigenen Benutzernamen anlegen, statt direkt nach /scratch/tmp zu schreiben! Dort wird es sonst sehr unübersichtlich.

Es wird kein Backup dieser Partition durchgeführt!

-- HolgerAngenent - 2010-07-12