Der High Performance Computing Cluster des GFZ wird vom Rechenzentrum betrieben und steht allen Mitarbeitern für Berechnungen zur Verfügung, für die ein normaler Arbeitsplatzcomputer nicht ausreicht.

Administratorin ist Marina Köhler, bei der der auch der Zugang beantragt werden kann, per E-Mail an koe@gfz-potsdam.de.

Die Seiten des Rechenzentrums geben auch einen ersten Überblick. Die dort vorhandenen Informationen sollten jedem Nutzer bekannt sein und werden hier nicht widerholt:

• Startseite
• Allgemeine Informationen
• Starten von parallelen und seriellen Anwendungen
• Übersicht über die Knoten
• Übersicht über die Queues

Bei Fragen und Problemen kann man sich an die folgenden Stellen wenden:

• Marina Köhler, die Administratorin, per Mail koe@gfz-potsdam.de oder Ticketsystem des RZ
• Kollegen, die auf dem Cluster arbeiten
• Jan Thaler jantha@gfz-potsdam.de, Cegit
• Die Mailingliste hpcluster-l@gfz-potsdam.de

Ein Server “glic” existiert physikalisch nicht, tatsächlich landet man entweder auf “glic1” oder “glic2”, je nachdem welcher davon gerade aktiv ist. Theoretisch sollte die Umgebung auf beiden Servern identisch sein. Wer Unterschiede feststellt, z.B. weil etwas nach einem Wechsel des Zugangsknotens nicht mehr so funktioniert wie gewohnt, sollte dies der Adminstratorin melden.

Im Normalfall ist der Benutzer über ssh auf dem Zugangsknoten angemeldet. Wer die Kommandozeile vermeiden möchte, kann alternativ eine der folgenden Oberflächen für praktisch alle Aufgaben benutzen:

• xsub
• Weboberfläche von LSF

Die Ressourcen des Clusters werden von der Platform Load Sharing Facility (LSF) verwaltet. Programme laufen auf dem Cluster als Jobs und werden zur Ausführung in Queues eingestellt. Die Queues leiten den Job dann an einen oder mehrere Prozessoren / Hosts weiter. Queues unterscheiden sich unter anderem darin ob (und wenn ja wieviele) Prozessoren parallel genutzt werden, wie hoch die Priorität ist und wie lang die Ausführung brauchen wird. Einige Queues sind für bestimmte Benutzergruppen reserviert. Dieses Verfahren sichert eine gleichmäßige und gerechte Auslastung des Clusters. Das direkte Starten eines Programms auf dem Cluster unter Umgehung der LSF ist daher nicht erlaubt.

Im Normalfall ist die Umgebung nach dem Login für den PGI Compiler sowie parallele Anwendungen mit MPI eingestellt. Mit dem Befehl module kann die Umgebung geändert werden. Beim Ausführen von mit MPI parallelisierten Programmen wird die aktuelle Umgebung für alle Knoten auf denen Prozesse gestartet werden teilweise kopiert.

Ausnahmen

• openmpi-intel: Hier wird die Umgebung nur auf den ersten Knoten kopiert, nicht jedoch auf weitere Knoten. Damit Variablen wie z.B. PATH, LD_LIBRARY_PATH richtig gesetzt sind sollte man die entsprechenden Module in im Initialisierungsskript seiner Shell (z.B. .bashrc) laden. Dies wird auf jedem Knoten ausgeführt, bevor das parallele Programm gestartet wird. Bei Verwendung eines Jobskripts kann man alternativ die Variablen auch mit dem Parameter -x an mpirun übergeben.
• mvapich-pgi: Hier wird nur die Umgebung aus dem Initialisierungsskript der Shell (z.B. .bashrc) eingerichtet. Wenn eigene Umgebungsvariablen (z.B. OMP_NUM_THREADS) benutzt werden sollen, so müssen diese in das Initialisierungsskript eingetragen werden. In dieser Konfiguration unterstützt mpirun keine Umgebungsvariablen als Parameter.

Durch die mit module gesetzten Pfade kann der passende Compiler mit den nötigen Bibliotheken angeprochen werden. Je nachdem, ob die Anwendung für parallele Ausführung programmiert ist, unterscheidet sich der Befehl. Beispiele:

• Kompilieren einer parallelen Anwendung: mpicc -o myapp_parallel my_application_parallel.c
• Kompilieren einer nichtparallelen Anwendung: pgcc -o myapp_serial my_application_serial.c

Es gibt mehrere Möglichkeiten das Programm an das LSF zu übergeben. Alle verwenden den Befehl bsub.

bsub kennt eine Reihe von Parametern, mit denen die Ausführung des Programms angepasst werden kann. Die wichtigsten sind folgende:

• -n <Anzahl der Prozessoren> fordert die entsprechende Anzahl an Prozessoren für parallele Ausführung an (default ist 1)
• -q <Name der Queue> schickt das Programm an die entsprechede Queue (default ist die Default-Queue)
• -o <Name der Ausgabedatei> leitet die Ausgabe in die entsprechende Datei, wobei ein %J automatisch durch die vom LSF vergebene eindeutige Job-Id ersetzt wird (default ist Ausgabe per E-Mail an den Benutzer)

Der genaue Aufruf unterscheidet sich, je nachdem ob die Anwendung parallel ausgeführt werden soll oder nicht und ist auf den Seiten des Rechenzentrums beschrieben.

: Jobskript erklären

Die Ausführung des Jobs kann man unter anderem mit folgenden Befehlen verfolgen:

• bjobs zeigt den Status aller laufenden eigenen Programme an. Durch verschiedene Parameter können auch andere Jobs oder weitere Informationen angezeigt werden.
• bhist -l nnn zeigt Informationen zum Job mit Id “nnn” an, der auch schon beendet sein kann.
• bkill nnn beendet die Ausführung des (eigenen) Jobs mit Id “nnn”.
• bpeek nnn zeigt die Ausgabe des Jobs mit der Id “nnn”. Wird die Id weggelassen zeigt er die Ausgabe des zuletzt gestarteten Jobs.

Die folgenden Befehle geben weitere Informationen über den Cluster, es gibt aber noch viele mehr.

• lsid zeigt allgemeine Informationen über den Cluster
• lshosts / bhosts zeigt alle Hosts
• bmgroup zeigt alle Hostgruppen
• bqueues zeigt alle Queues

Beim Debuggen von Programmen auf dem Cluster sind einige Punkte zu beachten:

• Das Programm muss es mit der Option -g compiliert werden.
• Die Umgebungsvariable TOTALVIEW muss gesetzt sein und den Dateinamen inklusive Pfad von Totalview enthalten: /opt/totalview/bin/totalview.
• Das Programm darf (vorerst) nicht auf den normalen Knoten laufen, sondern nur lokal auf dem Rechner an dem man eingeloggt ist (glic).
• mpirun muss mit speziellen Parametern gestartet werden um totalview einzubinden.
  Beispiel: mpirun -tv -np 2 -machinefile ./local ./myapp startet das Programm myapp auf 2 Prozessoren über Totalview. In der Datei local sollte als Host nur glic vorkommen. Es öffnet sich nun ein Fenster von Totalview, in dem man weitere Parameter angeben kann. Dies ist aber nicht nötig, da die Parameter bereits auf der Kommandozeile spezifiziert wurden. Nach Klick auf “OK” kann man mit dem Debuggen des Programms beginnen.

Neben selbstgeschriebenen Programmen wurden auch Erfahrungen mit der Parallelisierung von fertigen Programmen auf dem Cluster gemacht:

• Matlab (Marina Köhler koe@gfz-potsdam.de)
• GRASS GIS ist installiert und für alle nutzbar, siehe GIS-Wiki (Peter Löwe ploewe@gfz-potsdam.de / Jan Thaler jantha@gfz-potsdam.de)
• Paraview (Peter Löwe ploewe@gfz-potsdam.de / Jan Thaler jantha@gfz-potsdam.de)
• R (Stefan Luedtke sluedtke@gfz-potsdam.de / Jan Thaler jantha@gfz-potsdam.de)

PGI Users Guide

MPI Doc

TotalView Doc