Für rechen- und speicherintensive Aufgaben stehen im Forschungsrechnerbereich drei Cluster aus 64bit-Opteron- und Westmere-Rechnern zur Verfügung. Die einzelnen Rechner der Cluster sind weitestgehend kompatibel mit den Arbeitsplatzrechnern des Instituts und erlauben damit die einfache Auslagerung rechenintensiver Arbeiten vom Arbeitsplatzrechner auf die Cluster. Anderseits können durch spezifische Kompilierung von Programmen für diese Rechnerarchitektur eigene Programme deutlich beschleunigt werden, insbesondere wenn sogar die Möglichkeit der Parallelverarbeitung genutzt wird.

Weitere Möglichkeiten zur Bearbeitung rechen- und speicherintensiver Aufgaben stehen Ihnen im erweiterten Compute-Serverbereich des Institutes zur Verfügung, der dem Forschungsrechnerbereich angegliedert ist. Für diesen Bereich muss man sich gesondert anmelden. Bitte informieren Sie sie sich über die Möglichkeiten und Bedingungen auf den Dokumentationsseiten zum Compute-Serverbereich [1].

Im folgenden finden Sie detailierte Angaben zur Nutzung der Cluster im Forschungsrechnerbereich:

• Technische Daten
  
• Auslagerung kleinerer Programme
  
• Format eines Job-Scripts
  
• Jobs mit grossem Memory-Bedarf, Multi-Threaded Programme
  
• Überprüfen der Queues und der Clusternutzung
• Ändern und Löschen von Jobs
• Array Jobs (viele ähnliche Jobs mit verschiedenen Daten)
  
• Parallele Programme mit MPI
  
• Entwicklungswerkzeuge
• Entwicklungswerkzeuge für MPI Programme
• Relevante Manual-Pages
  
• Betreuung/Kontakt
  

Cluster 1 (Alt, derzeit ausgeschaltet)

Cluster 2

Cluster 13

Cluster 16

Cluster 18

Cluster 22

Für die einfachste Nutzung des Clusters, insbesondere für interaktive Programme (d.h. mit User-Input), benutzt man am besten das cluster-Kommando. Beispiele:

% Cluster -V matlab -nosplash -nodisplay < inp

oder einfach:

% Cluster -V matlab

(In den obigen und den folgenden Beispielen ist % jeweils der Kommando-Prompt
der Shell)

Anmerkung:  In früheren Versionen dieser Anleitung wurde das Cluster-Kommando mit kleinem 'c' geschrieben. Wegen eines Namens-Konflikts in neueren Linux-Versionen sollte ab jetzt die großgeschriebene Variante benutzt werden.

Das Cluster-Kommando startet die Programme im selben Directory, in dem Cluster aufgerufen wurde, vorausgesetzt, dass genügend Platz auf dem Cluster frei ist. Falls dies nicht der Fall ist, beendet Cluster mit einer entsprechenden Fehlermeldung. In solchen Fällen empfiehlt es sich, die Programme im Batch-Mode in die Queue zu stellen. Das Programm bleibt dann in einer Warteschlange und startet, wenn entsprechende Ressourcen auf dem Cluster frei werden. Für interaktive Programme wie im zweiten Beispiel oben ist dies nicht unbedingt sinnvoll, für das erste Beispiel jedoch durchaus. Wie man das macht, illustrieren die folgenden Beispiele:

1. Mit der -now no Option zu Cluster:

% Cluster -now no matlab -nosplash -nodisplay < inp

2. Durch Schreiben eines kleinen Job-Scripts und Abschicken desselben mit qsub:

% cat > matlab.job <<EOF
#!/bin/bash --login
#$ -cwd
#$ -N matlab
#$ -o matlab.out
#$ -j y
matlab -nosplash -nodisplay < inp
EOF
% qsub matlab.job

Statt 'cat' kann natürlich auch ein beliebiger Texteditor zur Erstellung des Job-Files benutzt werden.
Der Unterschied zwischen beiden Methoden ist, dass im zweiten Fall der Job komplett unabhängig von der aktuellen Terminal-Session abgearbeitet wird. Im ersten Fall muss das Fenster offen bleiben.

Noch einmal das obige Beispiel mit Zeilennummern und ein paar mehr Parameter-Zeilen:
 

Erläuterung:
2) Wechselt ins Verzeichnis, aus dem der Job abgeschickt wurde.
3) Jobname
4) Output-File
5) 'Join'=yes, d.h. Errors zusammen mit Output ins Output-File
6) Angabe der maximalen Laufzeit (in Sekunden).
7) Mail bei Beginn und Ende des Jobs schicken
8) Mail-Adresse (bitte angeben !!)

Die Angabe der maximalen Laufzeit wird dringend empfohlen. Der Cluster-Scheduler wird zum Einen kurze Jobs bevorzugen und zum Anderen besteht ohne weitere Angaben ein Laufzeitlimit von 12 Stunden. Des weiteren besteht eine Obergrenze für die Memory-Allocation von 2GB damit der zweite Prozessor und die andere Hälfte des Speichers noch für andere Jobs verwendet werden können. Siehe unten für Möglichkeiten, mehr Memory zu nutzen.
Sämtliche Job-Parameter, die in einem Script benutzt werden können, dürfen auch auf der Kommandozeile von qsub benutzt werden und haben dann höhere Priorität:

% qsub -N test -l h_rt=80000 jobscript
% Cluster -N test2 -pe mp 2 matlab -nosplash -nodisplay < inp

Programme, die das ganze Memory von 4GB (rsp. 16GB oder 32GB) nutzen wollen oder mit mehreren Threads oder Prozessen arbeiten, sollten jeweils eine Cluster-Node mit zwei oder vier Prozessoren komplett reservieren. Dies erreicht man mit der zusätzlichen Zeile

#$ -pe mp 2 -l cluster1

oder

#$ -pe mp 4 -l cluster2

im Job-Script. Im ersten Falle läuft der Job auf einem 4GB-Knoten mit 2 Prozessoren, im zweiten mit (mind.) 16GB und 4 Prozessorkernen.

Das Kommando qstat zeigt die laufenden und wartenden Jobs an:

% qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
4636 0.50500 matlab zeppo r 08/31/2006 22:19:48 all.q@node02 2
4531 0.50500 comsol pippo r 08/25/2006 18:05:38 all.q@node04 2
4632 0.50500 meinprog blump r 08/31/2006 10:12:18 all.q@node07 2
4621 0.55500 mpitest npasched qw 09/01/2006 08:44:36 10

Einige der Job-Parameter können auch nach dem Abschicken des Jobs noch geändert werden, teilweise sogar noch wenn der Job schon läuft. Hierzu dient das Kommando qalter. Es kennt im Wesentlichen dieselben Optionen wie qsub und setzt die entsprechenden Parameter für die angegebene Job-ID.
Jobs, die falsch aufgesetzt, abgeschickt oder sonstwie beseitigt werden sollen, werden mit dem Kommando qdel unter Angabe der Job-ID entfernt.
Beispiel:

% qstat -u npasched
job-ID prior name user state submit/start at queue slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
4621 0.55500 mpitest npasched qw 09/01/2006 08:44:36 10
% qalter -m a 4621
modified mail options of job 4621
% qdel 4621
npasched has deleted job 4621

Es kommt ab und zu vor, dass ein Job-Script mit einer grossen Anzahl Datensätzen laufen soll und dies im Prinzip auch parallel tun könnte. Die offensichtliche Methode, nämlich einfach n nur leicht differierende Job-Scripts zu schreiben und abzuschicken, ist sicherlich ab n > 3 eher lästig.
Eine elegantere Lösung sind sog. Job-Arrays, wo ein einziges Job-Script abgeschickt wird, versehen mit der Weisung in n Kopien zu starten.
Ein entsprechendes qsub Kommando sieht so aus:

% qsub -t 10-30:2 jobscript

Das obige Kommando schickt das Script jobscript ins Batch-System und erzeugt dort 11 Kopien, die jeweils eine sog. TASK_ID zugewiesen bekommen im Bereich [10..30] mit
Abstand 2, also 10 12 14 16 ....
Im Job-Script steht die Task-ID an zwei Stellen zur Verfügung:

1. Im Script-Header:
Hier können z.B. die Namen der Output-Files um die Task-ID ergänzt werden, so dass jede Kopie in ein eigenes File schreibt:

#$ -o job.$TASK_ID.out

2. Im Script selbst:

Hier steht die Task-Id in der Environment-Variable $SGE_TASK_ID und kann im Script selbst oder in von dort gestarteten Prozessen gelesen und genutzt werden.

#!/bin/bash --login
#$ -cwd
#$ -N matlab_run
#$ -o matlab_run.$TASK_ID.out
#$ -j y
#$ -m be
#$ -M myself@math.tu-berlin.de

matlab -nosplash -nodisplay < input.$SGE_TASK_ID.m

Hier noch ein Beispiel für einen Matlab-Input, der die Task-ID direkt liest:

task_id = str2num( getenv('SGE_TASK_ID') )

x = floor( task_id / 160 )
y = task_id - x * 160

.....

Weiter nutzbare Environment-Variablen:

• $SGE_TASK_LAST : Die letzte Task-ID
• $SGE_TASK_STEPSIZE : Der angegebene Step-Size.

Für paralle Programme mit MPI sollte man ein Job-Script ähnlich dem folgenden benutzen:

#!/bin/bash --login
#$ -cwd
#$ -pe ompi* 4
#$ -N mpitest
#$ -o mpitest.out
#$ -j y
#$ -m be
#$ -M myself@math.tu-berlin.de

module add ompi-1.2.2

mpirun -np $NSLOTS myprog

Die rote vier gibt hier die gewünschte Anzahl Prozessoren an. Es kann sogar ein
Bereich von Prozessoren gewünscht werden:

#$ -pe ompi* 2-8

was den Job mit zwischen 2 und 8 Prozessoren startet (je nachdem was frei ist). Die
tatsächlich alloziierte Anzahl ist im Script dann über die Variable $NSLOTS
abrufbar.

Die sog. "Parallel Environments" ompi*, wie in den obigen Beispielen
mit -pe angefordert werden, sind eine Art Gruppierung für die eigentlichen Queues.
Sie bestimmen bei Anforderung von mehr als einem Queue-Slot, ob und wie die Prozesse auf die
Knoten verteilt werden. Wegen der Netzwerktopologie der beiden Cluster gibt es eine ganze Reihe
dieser ompi* PEs, das '*' in der oben gezeigten Anforderung bedeutet: Nimm irgendeines
dessen Name mit 'ompi' anfängt.

Die folgende Liste zeigt alle verfügbaren PEs:

Es bedeuten hier:

n: so wie angegeben
fill: Ein Knoten bekommt so viele Prozesse wie Platz ist, dann kommt der nächste Knoten dran.
*: egal

Das -pe kann also auch so aussehen:

#$ -pe mpi1 2-8

Für Programme, die mit OpenMPI kompiliert wurden, sollten NUR die ompi* PEs benutzt werden.

Die PEs mit Namen 'mpi*' sind für Programme, die ein Ethernet-basiertes MPI
verwenden.

Für den Cluster und die anderen 64bit-Rechner im Institut wurden eine Reihe von zusätzlichen Compilern installiert, die, was die Optimierung für Opteron-Prozessoren angeht, eine höhere Performance versprechen als die normalen gcc Versionen.
Hier eine Übersicht:

^{1) teilweise
2) Seit Ende Nov. 08 sind keine Lizenzen mehr verfügbar}

Nicht alle Compiler sind im normalen Suchpfad vorhanden. Wenn eine spezielle Version benötigt wird, können die entsprechenden Environment-Variablen mit dem module Kommando gesetzt werden. Beispiel:
% module add pathscale-2.2.1

Der Name des Moduls kann der obigen Tabelle entnommen werden und wird mit der
entsprechenden Versionsnummer ergänzt. Mit module avail erhält man
eine Liste der verfügbaren Module:

% module avail

------------------- /usr/share/modules/modulefiles -----------------------

dot ifc9.1.36 mvapich-pgi-0.9.8 use.own

g03 lahey8.0 null

gaussian03 module-cvs pathscale-2.0

gcc402 module-info pathscale-2.1

gcc411 modules pathscale-2.2.1

gridengine mpich-ch-p4 pathscale-2.3

icc9.0 mpich-ch-p4mpd pathscale-2.3.1

icc9.0.23 mvapich-gcc pathscale-2.4

icc9.1 mvapich-gcc-0.9.8 pathscale-2.5

icc9.1.42 mvapich-intel-0.9.8 pgi-6.0.5

ifc9.0 mvapich-pathscale pgi-6.1

ifc9.0.25 mvapich-pathscale-0.9.8 pgi-6.2.5

ifc9.1 mvapich-pgi starcd-3.24

Nicht alle aufgelisteten Module betreffen Compiler. Informationen zu einem bestimmten Modul erhält man mit (z.B.):

% module help pgi-6.0.5

----------- Module Specific Help for 'pgi-6.0.5' ------------------

Sets up the paths you need to use the Portland 6.0.5 compiler suite as the default

Bei häufiger Benutzung bestimmter Module ist es sinnvoll, entsprechende module-Befehle im ~/.cshrc- oder ~/.bashrc-File unterzubringen. Beispiel:

% tail ~/.cshrc

if ( ${?MODULESHOME} ) then
module load pathscale-2.4 gcc411
endif

#end of .cshrc

Für die Compilierung von MPI-Programmen sollte man die jeweiligen MPI-Compiler-Wrapper mpicc, mpif77 etc. benutzen, die einen der oben genannten Compiler aufrufen und die korrekten MPI-Bibliotheken dazulinken. Die hierfür relevanten Module heissen:

cluster, qrsh, qsub, qstat, qalter.

Die Cluster werden betreut von

• Norbert Paschedag, MA 368, Tel. 314 29264

• Sven Grottke,  MA 368, Tel.: 314 29283

Bei Fragen zum Cluster oder Problemen mit der Nutzung senden Sie bitte eine Email an die Betreuer [2](clust_staff)http://www.math.tu-berlin.de/cgi-bin/revchaddr.pl?ed.nilreb-ut.htam*ffats_tsulc [3]