Wissenschaftliche Rechnungen auf CLiC

Der HPL-Benchmark

Benchmarks wurden und werden entwickelt, um Programme und Computer nach bestimmten Kriterien vergleichbar zu machen. Insbesondere in der Kategorie Supercomputer ist die Rechenleistung ein solches interessierendes Kriterium. Seit 1993 wird eine Top500-Liste der weltweit größten Supercomputer geführt, initiiert durch Hans Meuer (Mannheim) und Jack Dongarra (Tennessee). Diese Rangliste beruht auf dem sogenannten HPL-Benchmark (High Performance Linpack). Dabei besteht die Aufgabe darin, ein vollbesetztes lineares Gleichungssystem mittels Gauß-Elimination zu lösen, und das so schnell wie möglich für eine sehr große Anzahl von Unbekannten. Man kennt die Zahl der dafür notwendigen Rechenoperationen: . Dividiert man diese durch die gemessene Rechenzeit, so erhält man die Gesamtleistung des Superrechners, die inzwischen nicht mehr in Mflops, sondern in Gflops angegeben wird. Es gibt eine Reihe von Faktoren, die diese Leistung beeinflussen, z.B. die hinsichtlich Cache-Nutzung optimale Implementierung der BLAS-Routinen, insbesondere derjenigen zur Matrixmultiplikation. Bei Clustersystemen wie unserem CLiC spielt auch die Kommunikationsleistung eine entscheidende Rolle. Der Rechenaufwand lässt sich nur dann erfolgreich auf viele Prozessoren verteilen, wenn diese ihre Teilergebnisse auch hinreichend schnell austauschen können. Hardware (Netz, Switch) und Software (MPI-Bibliothek) müssen mit einer so großen Anzahl von Prozessoren zurechtkommen. Schließlich hat ein solches Benchmark-Programm zahlreiche Parameter, mit denen durch noch zahlreichere Tests eine Konfiguration für optimale Rechenleistung zu finden ist. Was bringt uns dieser Benchmark außer einer enormen "Verschwendung" von Rechenzeit?

• Da solche Benchmark-Rechnungen sehr lange dauern und dabei sehr viele Ressourcen intensiv benutzen, wird damit gerade nach der Installation eines neuen Rechners ein wichtiger Test der Funktionsfähigkeit und Zuverlässigkeit aller Komponenten realisiert.
• Nebenbei erhält man einen begehrten Eintrag in der Weltbestenliste der Top500 Supercomputer. Im vergangenen Jahr hatten wir mit 143 Gflops eine gute Platzierung erreicht:

  (Nov. 2000)	weltweit	in Europa
  alle Supercomputer	126	31
  Clustersysteme	13	3
  "self-made"	2	1

Ab Juni 2001 reichte diese Leistung noch für Platz 156. Aber durch weitere Verbesserungen an Hard- und Software gelang vor wenigen Wochen eine nochmalige Steigerung der Bestmarke auf etwa 222 Gflops. Die dazugehörige Platzierung ist in diesen Tagen wieder unter http://www.top500.org verfügbar.
Bei diesem Test auf insgesamt 529 Prozessoren wurde ein System mit 176640 Unbekannten in 4 Stunden und 36 Minuten gelöst. Allein für die Koeffizientenmatrix dieses Systems war dabei ein Gesamtspeicher von 238050 MByte (=232 GByte) RAM erforderlich, was sogar übliche Festplatten überfordert hätte.

Das Diagramm (Bild 1) zeigt einige bemerkenswerte Resultate, die während der umfangreichen Tests mit dem HPL-Benchmark-Programm erzielt wurden und eindrucksvoll die Leistungsfähigkeit des CLiC belegen:

• Die Leistung ist nahezu proportional zur Anzahl der verwendeten Prozessoren. Die gestrichelte Linie zeigt zum Vergleich das Optimum, das man erreicht hätte, wenn keine Kommunikation zwischen den Prozessoren notwendig wäre.
• Die durchschnittliche Leistung jedes einzelnen Prozessors liegt mit 420 Mflops trotz Kommunikation noch über 50% der theoretischen Peak-Leistung (800 Mflops beim Pentium-III/800 MHz).
• Der Einzelprozessor schafft hier mit 615 Mflops eine außerordentlich gute Rate von fast 77% dieser theoretischen Obergrenze.

Eine große FE-Rechnung "akademisches Beispiel"

Der Demonstration einer Super-Rechnung mit echtem wissenschaftlichen Interesse (Bsp. 3) stellen wir ein "akademisches Beispiel" voran. Dieses Beispiel steht gewissermaßen zwischen obigem Benchmark, der nur der Informationsgewinnung über die Maschine dient und einer richtigen Anwendung, wo natürlich die allerletzte Ausnutzung von Parallelität, ideale Balance zwischen den Prozessoren usw. zurücktreten muss zugunsten von Ergebniserlangung in realistischer Zeit (sowohl Zeit für die Programmerstellung als auch Rechenzeit).

Unser "akademisches Beispiel" ist so angelegt, dass der verwendete Algorithmus hinsichtlich Parallelisierung die typische Anwendung bei Aufgaben mit partiellen Differentialgleichungen repräsentiert. Untypisch ist aber hierbei, dass das Rechengebiet extrem einfach ist. Weiterhin wird eine völlig gleichmäßige Diskretisierung gewählt. Dies hat zur Folge, dass man garantieren kann, dass die Parallelisierungsidee "DD-domain decomposition" (also Zerlegung des Gebiets in p Teilgebiete bei p Prozessoren) eine exakt gleiche Rechen- und Datenlast in allen Prozessoren erzeugt. Auch der Kommunikationsaufwand ist ideal parallelisiert. Das einzig beeindruckende an diesem Beispiel ist die Möglichkeit durch fortgesetztes Halbieren aller Kanten in einem Startnetz (Vierteln aller Dreiecke) beliebig hohe Dimensionen des zu lösenden Gleichungssystems zu erzeugen - solange der Speicherplatz pro Prozessor dies zulässt.

Der wesentliche Unterschied zum Benchmark in Beispiel 1 besteht darin, dass die bei der FEM entstehenden Matrizen hier schwach besetzt sind, also nur Nichtnullelemente für diese Matrizen (in besonderen Listen) gespeichert werden müssen. Weiterhin kommt zum Lösen der Gleichungssysteme ein modernes Iterationsverfahren (hier das Verfahren der konjugierten Gradienten mit hierarchischer Vorkonditionierung) zum Einsatz. Deshalb ist die Anzahl der notwendigen Operationen (und der Speicherplatz) proportional zur Anzahl der Unbekannten N, weshalb Unbekannten-Zahlen von fast 100 Millionen hier ohne weiteres möglich sind und noch Rechenzeiten unterhalb einer Minute ermöglichen. Das Testbeispiel repräsentiert die Lösung einer Diffusionsgleichung in einem quadratischen zweidimensionalen Gebiet (s. Bild 2/3), was zum Beispiel eine Wärmeverteilung in einem Blech oder die Schadstoffausbreitung in einer Erdschicht (oder vieles anderes mehr) sein könnte.

Für alle diese praxisrelevanten Simulationsrechnungen würde man niemals diese extrem feine Vernetzung in viele Millionen Gitterpunkte benötigen, aber man kann hiermit eindrucksvoll die Möglichkeiten von CLiC aufzeigen:

Bild 2/3: Netz und Lösung

Wir wollen durch Erhöhung der Prozessoranzahl immer schneller rechnen können. Dies zeigt die Tabelle 1 in beeindruckendem Maße: Das Ausgangsnetz mit 128 Grobdreiecken wurde 5- bis 9-mal fortgesetzt geteilt, so dass die in Spalte 2 angegebenen Unbekanntenzahlen entstehen, die man auf wenigen Prozessoren unmöglich bearbeiten kann. Unser Löser berechnet die jeweilige Lösung (unabhängig von der Prozessoranzahl) in 34..36 Iterationen. (Die Konstanz dieser Zahl ist notwendig für obige Aussage: Zeit ). Nutzt man nun zwischen 16 und 128 Prozessoren des CLiC, so ergeben sich die angegebenen Zeiten (in Sekunden!). Zum Beispiel in der Zeile L=8 kann man wunschgemäß Zeitverhältnisse wie fast ablesen, (exakt steht 1 : 0.503 : 0.244 : 0.131).

In Klammern sind die durchschnittlichen Anteile an Kommunikationszeiten aller Prozessoren angegeben, die immer dann unter 5% kommen, wenn die Gesamtdatenlast pro Prozessor groß genug ist. (Bemerkung: Von Level zu Level wächst theoretisch der Arithmetikaufwand um den Faktor 4, der Kommunikationsaufwand nur auf das Doppelte, so dass eine Halbierung dieser Prozentzahlen in allen Spalten die Güte unserer Inter-Prozessor-Kommunikation ausweist.)

Eine große FE-Rechnung "real life"

Um zu zeigen, dass solche Rechenleistungen für einige wissenschaftlich technische Berechnungen unabdingbar sind, soll dieses dritte Beispiel angeführt werden. Es handelt sich um den "Deutschen Strömungsbenchmark", der vor einigen Jahren von Heidelberger Wissenschaftlern ausgerufen (und ausgewertet) wurde, um die vielen Strömungscodes in Deutschland hinsichtlich Ergebnisqualität zu bewerten. Dabei hatten sich recht viele Arbeitsgruppen mit 2D-Benchmarkrechnungen beteiligt, aber bei der echt 3-dimensionalen Strömungssimulation waren nur so wenige Ergebnisse vorhanden, dass man eigentlich keine Aussagen treffen konnte. Auch vom SFB 393 wurden damals 3D-Beiträge (Rechnung auf GC Power Plus-128) eingereicht, die aber nur unzureichende Diskretisierungsfeinheit aufweisen mussten (wegen des viel zu kleinen Speicherausbaus dieser Maschine).

Auf CLIC kann man jetzt in neue Größenordnungen vorstoßen und folgende Vernetzungen bewältigen:
Das Strömungsgebiet ist hier ein langer Kanal, in dem (senkrecht) ein zylinderförmiges Hindernis umströmt wird. Die Anströmgeschwindigkeit ist so hoch, dass eine instationäre Strömung entsteht, die über einige Sekunden zu verfolgen ist, um typische Parameter (Abtrieb des Zylinders, der neben der Mitte liegt, und Wirbelfrequenz) zu erkennen. Ein Startnetz aus 700 Hexaedern wurde hierzu 3-mal verfeinert (ergibt das 8³-fache an Elementen und etwa 12 Millionen Freiheitsgrade). Dies ist damit eine typische Rechnung bei 3-dimensionalen Aufgabenstellungen, die, ab der hier benutzten Netzfeinheit, die Chance auf realistische Ergebnisse bietet. Der enorme Zeitaufwand für solche Simulationen resultiert hauptsächlich aus dem zeitabhängigen Charakter der Lösung. Deshalb muss man die Zeitachse in kleine Schritte diskretisieren und je eine Rechnung vom Typ wie in Beispiel 2 für den Übergang von Zeitpunkt t_k zum Zeitpunkt t_k+1 durchführen. Um die Strömung etwa 10 s (Realzeit) zu verfolgen, werden so mindestens 1000 solche Zeitschritte nötig. Auf CLiC kann man immerhin einen solchen Zeitschritt in etwa 30 s bewältigen, so dass für die gesamte Simulation schon 8 Stunden reine Rechenzeit entstehen. Dies reicht bei weitem nicht aus, da hier zusätzlich ein beträchtlicher Aufwand für die Ergebnisdarstellung nötig ist (z.B. Speichern des Strömungsfeldes als 1 Bild pro Zeitschritt, woraus am Ende ein filmischer Ablauf rekonstruiert werden kann). Deshalb wurden für eine vollständige Simulation fast 24 Stunden benötigt. Das Bild 4 gibt somit einen Schnappschuss der Strömung wieder, die filmischen Abläufe stehen im Web unter http://www.tu-chemnitz.de/sfb393/software/cfd-exmpls.html bzw. http://www.tu-chemnitz.de/sfb393/qt/bm-xyzp_20-31s_small.mov

Bild 4: Zylinderumströmung, Schnittebene mit verschiedenen Lösungskomponenten