GPU Acceleration and Portability of the TRIMEG Code for Gyrokinetic Plasma Simulations using OpenMP

Diese Arbeit präsentiert die erfolgreiche Portierung des TRIMEG-Gyroneutronen-Plasmasimulationscodes auf GPU-Architekturen unter Verwendung der portablen OpenMP-API, wobei signifikante Beschleunigungen und verifizierte physikalische Genauigkeit durch hybride MPI-OpenMP-Parallelisierung und Simulationen des Ionen-Temperaturgradienten-Modus nachgewiesen werden.

Das Wesentliche

Das große Ganze: Einen kosmischen Sturm kochen

Stellen Sie sich vor, Sie wollten das Wetter innerhalb eines Sterns vorhersagen. In der realen Welt können wir nicht einfach ein Thermometer in die Sonne oder in einen Fusionsreaktor stecken; es ist zu heiß und zu chaotisch. Stattdessen nutzen Wissenschaftler Supercomputer, um „virtuelle Simulationen“ von Plasma (einem superheißen, elektrisch geladenen Gas) durchzuführen.

Der TRIMEG-Code ist ein spezielles, sehr ausgeklügeltes Rezept zur Simulation dieses Plasmas. Er verfolgt Milliarden winziger Teilchen (wie einzelne Sandkörner in einem Sturm), um zu sehen, wie sie wirbeln, kollidieren und Turbulenzen erzeugen. Das Problem? Dieses Rezept ist unglaublich schwerfällig. Es auf einem Standardcomputer (CPU) laufen zu lassen, ist so, als würde man versuchen, einen Berg mit einem einzigen Löffel zu bewegen. Es dauert zu lange.

Das Ziel: Der Autor, Giorgio Daneri, wollte dies beschleunigen, indem er GPUs (Grafikprozessoren) nutzt. Betrachten Sie eine CPU als einen einzelnen Chefkoch, der sehr intelligent ist, aber immer nur ein Gemüse gleichzeitig schneiden kann. Eine GPU ist wie eine Küche mit 10.000 Sous-Chefs, die alle gleichzeitig Gemüse schneiden können. In der Dissertation geht es darum, herauszufinden, wie man das Rezept des einzelnen Chefkochs perfekt auf eine Armee von 10.000 Sous-Chefs überträgt – und zwar so, dass es für zwei verschiedene Marken von Küchen (NVIDIA und AMD) funktioniert.

Die Herausforderung: Das Problem des „Universellen Übersetzers“

Der Autor entschied sich für ein Werkzeug namens OpenMP, um die Übersetzung durchzuführen. Stellen Sie sich OpenMP als einen universellen Übersetzer vor, der dem Computer sagt: „Hey, nimm diesen Teil des Rezepts und gib ihn an die GPU weiter.“

Der Autor stieß jedoch auf zwei große Hürden:

1. Der „Compiler“-Fehler: Die Software, die den Code übersetzt (der Compiler), war nicht perfekt. Es war, als würde man versuchen, einen universellen Übersetzer zu benutzen, der manchmal vergisst, wie man „Salz“ oder „Hitze“ sagt. Der Autor musste Teile des Codes umschreiben, um den Eigenheiten des Übersetzers gerecht zu werden. Zum Beispiel nutzte der Code fortgeschrittene „Polymorphie“ (eine schicke Art zu sagen, dass Objekte ihre Form oder Identität ändern können). Die Übersetzer (Compiler) für die GPUs verstanden dieses Formwandeln nicht, also musste der Autor die Formen in starre Boxen „abflachen“, um sie funktionsfähig zu machen.
2. Der „Verkehrsstau“: Das Verschieben von Daten zwischen dem Hauptcomputer (CPU) und der GPU (den Sous-Chefs) ist langsam. Wenn man ständig stoppt, um Zutaten hin und her zu reichen, sitzen die Sous-Chefs untätig herum. Der Autor musste den Code so umstrukturieren, dass alle Zutaten zu Beginn einmalig zur GPU bewegt werden, anstatt sie ständig hin und her zu pendeln.

Die Lösung: Die Küche umstrukturieren

Um den Code sowohl auf NVIDIA- als auch auf AMD-GPUs laufen zu lassen, musste der Autor eine Art „Operation“ am TRIMEG-Code durchführen:

• Die Karte abflachen: Der Code nutzte eine komplexe Karte, um zu finden, wo sich die Teilchen befanden. Diese Karte war wie ein unordentlicher Aktenschrank. Der Autor flachte sie in eine einzige, gerade Liste ab, damit die GPU sie sofort lesen kann, ohne sich zu verirren.
• Den „Race“ korrigieren: Manchmal, wenn tausende Sous-Chefs gleichzeitig auf dasselbe Whiteboard schreiben wollen, übermalen sie sich gegenseitig (eine sogenannte „Race Condition“). Der Autor fand Stellen im Code, an denen dies geschah, und korrigierte sie, sodass jeder in seiner eigenen Spur schreibt.
• Der „Einheitsmaß“-Kompromiss: Da die beiden GPU-Marken (NVIDIA und AMD) leicht unterschiedliche Sprachen sprechen, musste der Autor eine einzige Code-Version erstellen, die für beide funktioniert, selbst wenn dies bedeutete, einige „Umwege“ (wie die Nutzung einer spezifischen Art der Speicherzuweisung, die für beide funktioniert, auch wenn sie für den einen nicht absolut schnellste ist) einzubauen.

Die Ergebnisse: Hat es funktioniert?

Der Autor testete die neue GPU-Version gegen die alte CPU-Version anhand zweier berühmter „Testfälle“ (wie Standard-Fahrtests für ein neues Auto):

1. Der Zyklon-Fall: Eine vereinfachte Simulation von Plasma-Turbulenz.
2. Der TCV-X21-Fall: Eine komplexere, realistischere Simulation, die den Rand des Plasmas betrifft.

Das Urteil:

• Geschwindigkeit: Die GPU-Version war deutlich schneller. In einigen Tests war sie fast 30-mal schneller als die CPU-Version auf einer einzelnen Maschine.
• Genauigkeit: Die Ergebnisse der GPU stimmten fast perfekt mit den CPU-Ergebnissen überein. Die „Wettermuster“ (Energiewachstum und Turbulenzstrukturen) sahen identisch aus.
• Portabilität: Der Code lief erfolgreich auf sowohl NVIDIA- als auch AMD-Hardware, ohne dass er für jede einzeln komplett neu geschrieben werden musste.

Die Kehrseite (Einschränkungen)

Der Autor ist ehrlich bezüglich der Einschränkungen:

• Der „Übersetzer“ ist noch nicht perfekt: Die Compiler (die Software, die den Code in Maschinensprache umwandelt) für diese GPUs sind noch in der Entwicklung. Manchmal liefern sie leicht andere mathematische Ergebnisse als die CPU, was über die Zeit zu winzigen Fehlern führen kann.
• Hardware-Mismatch: Wenn man einen Computer mit vielen CPU-Kernen, aber nur einer GPU hat, könnte die GPU überfordert werden, wenn man versucht, ihr zu viele Aufgaben gleichzeitig zuzuweisen. Der Autor fand heraus, dass man für die besten Ergebnisse das Gleichgewicht zwischen der Anzahl der „Chefs“ (MPI-Prozesse) und der Anzahl der verfügbaren „Sous-Chefs“ (GPU-Threads) halten muss.
• Kein „Wundermittel“: Während der Teil des Codes, der die Teilchen bewegt, einen massiven Geschwindigkeitsvorteil erhielt, laufen andere Teile der Simulation (wie das Lösen der Magnetfeldgleichungen) weiterhin auf der CPU, da die Werkzeuge, um genau diese Teile auf die GPU zu verlagern, noch nicht bereit sind.

Zusammenfassung

Kurz gesagt, diese Dissertation ist eine Geschichte von ingenieurtechnischer Genialität. Der Autor nahm einen schweren, langsamen, komplexen Simulationscode und brachte ihm erfolgreich bei, auf modernen, leistungsstarken Grafikkarten zu laufen. Er navigierte durch ein Minenfeld aus Softwarefehlern und Compiler-Beschränkungen, um eine Version zu schaffen, die auf zwei verschiedenen Arten von Hardware funktioniert, und bewies damit, dass wir Fusionsplasma viel schneller simulieren können, ohne an Genauigkeit zu verlieren. Dies ist ein entscheidender Schritt, um die Forschung zur Fusionsenergie effizienter zu machen, auch wenn der Weg zu einer vollautomatischen, perfekten Übersetzung noch nicht ganz abgeschlossen ist.

Technische Zusammenfassung

Technische Zusammenfassung: GPU-Beschleunigung und Portabilität des TRIMEG-Codes für gyrokinetische Plasmasimulationen mittels OpenMP

Problemstellung
Plasmaphysik-Simulationen, insbesondere gyrokinetische Modelle zur Untersuchung von Instabilitäten und Turbulenzen in Tokamak-Fusionsreaktoren, sind rechenintensiv. Der TRIME-G-Code, ein hochpräziser Particle-in-Cell (PIC)-Solver, der eine C1-Finite-Elemente-Methode auf unstrukturierten Dreiecksnetzen verwendet, steht vor erheblichen Herausforderungen bei der Ausführungszeit aufgrund der massiven Anzahl an Teilchen (oft $10^7$ bis $10^8$), die für realistische Simulationen erforderlich ist. Obwohl der Code bereits MPI für die Multi-Node-Parallelität nutzt, stellen die Partikel-Pushing- und Grid-to-Particle (G2P)-Operationen den primären Flaschenhals dar und verbrauchen bis zu 80 % der gesamten Ausführungszeit. Die Herausforderung besteht darin, diese spezifischen „Hotspots“ mithilfe von Grafikprozessoren (GPUs) zu beschleunigen und gleichzeitig die Portabilität über verschiedene Hardwarearchitekturen (speziell NVIDIA und AMD) hinweg zu gewährleisten und die komplexe objektorientierte Struktur des Codes, die Polymorphie und abgeleitete Typen umfasst, zu bewahren.

Methodik
Die Studie konzentriert sich auf die Portierung des TRIMEG-Codes auf GPU-Architekturen unter Verwendung der OpenMP-Offloading-API (Version 4.0 und später). Die Methodik umfasste:

1. Zielauswahl: Der Partikel-Pusher-Kernel und die damit verbundenen G2P-Operationen (Pullback, Dichteberechnung und Interpolation der Verteilungsfunktion) wurden als primäre Ziele für das Offloading identifiziert, da sie eine hohe arithmetische Intensität aufweisen und keine Inter-Partikel-Abhängigkeiten besitzen.
2. Code-Restrukturierung für Portabilität: Eine signifikante Umstrukturierung war erforderlich, um die Einschränkungen der Compiler sowohl in amdflang (AMD) als de nvfortran (NVIDIA) zu überwinden. Zentrale Herausforderungen waren:
   • Polymorphie: Beide Compiler hatten Schwierigkeiten mit class() abgeleiteten Typen und typgebundenen Prozeduren innerhalb von GPU-Target-Regionen. Die Lösung bestand darin, den Code so zu restrukturieren, dass nach Möglichkeit nicht-polymorphe type() Deklarationen verwendet werden, und einen Workaround für zirkuläre Abhängigkeiten zwischen Partikel- und Feldklassen durch Basis-/Erweiterungsklassen-Hierarchien und Fortran INCLUDE-Direktiven zur Duplizierung von Funktionskörpern zu implementieren.
   • Dynamische Arrays: Der Code nutzte eine benutzerdefinierte Bibliothek, die C++ Vektoren nachahmt, für dynamische Arrays. Da GPU-Kernel Schwierigkeiten mit dynamischer Allokation oder komplexen Pointer-Indirektionen haben, wurde die Mapping-Struktur zwischen Bounding Boxes und Meshtriangeln von einem Array of Structures in 1D-Arrays „geflacht“, um effiziente Speicherübertragungen zu ermöglichen.
   • Speichermanagement: Eine präventive Speicherallokation wurde während der Initialisierungsphase implementiert, um die Laufzeitlatenz zu minimieren. Für AMD-Plattformen wurde, sofern möglich, Unified Shared Memory (USM) genutzt, während für NVIDIA-Plattformen ohne USM-Unterstützung explizite enter data, update und exit data Direktiven verwendet wurden.
   • Numerische Konsistenz: Um sicherzustellen, dass die GPU-Ergebnisse mit den CPU-Referenzen übereinstimmen, wurden Compiler-Optimierungen, die die Gleitkomma-Arithmetik verändern (wie Fused-Multiply-Add-Instruktionen), deaktiviert (-ffp-contract=off für AMD, -Mnofma für NVIDIA). Race Conditions in der externen B-Spline-Bibliothek wurden gelöst, indem von Shared-Object-Membern auf lokal deklarierte automatische Arrays umgestellt wurde.
3. Leistungsbewertung: Die Implementierung wurde auf den Clustern Viper (AMD MI300A), Raven (NVIDIA A100) und Pitagora (NVIDIA H100) getestet. Die Leistung wurde evaluiert durch:
   • Kernel-Profiling: Verwendung von rocprof-compute und nsys zur Analyse von Ressourcenbelegung, Speicherbandbreite und Instruktionsmischung.
   • Skalierbarkeitsstudien: Es wurden Strong-Scaling-Tests durchgeführt, um die Effizienz von Hybrid-MPI-OpenMP-Offloading zu bewerten, wobei insbesondere die Auswirkungen der Übersubskription von GPUs mit mehreren MPI-Prozessen untersucht wurde.
   • Exploration der Grid-Größen: Abstimmung der Anzahl der OpenMP-Teams und Threads pro Team zur Maximierung der Hardware-Ausnutzung.

Wesentliche Beiträge

• Erster herstellerübergreifender Port: Diese Arbeit stellt einen wegweisenden Versuch dar, einen komplexen, objektorientierten Fortran-Gyrokinetik-Code unter Verwendung von OpenMP-Offloading sowohl auf NVIDIA- als auch auf AMD-GPUs mit einem einzigen Codebase zu portieren.
• Compiler-Workarounds: Die Arbeit dokumentiert spezifische, nicht triviale Workarounds für Compiler-Einschränkungen hinsichtlich Polymorphie, dynamischer Arrays und Prozedur-Pointer in OpenMP-Target-Regionen. Sie hebt den Mangel an umfassender Dokumentation für nvfortran und amdflang bezüglich dieser Funktionen hervor.
• Analyse der hybriden Parallelisierung: Die Studie liefert eine detaillierte Analyse der Trade-offs beim hybriden MPI-OpenMP-Offloading und zeigt auf, dass die GPU-Beschleunigung zwar effektiv für den Partikel-Pusher ist, die fehlende OpenMP-Multithreading-Fähigkeit im Originalcode jedoch eine Übersubskription erforderlich macht, was die Skalierbarkeit auf Knoten mit hoher Kernzahl, aber begrenzten GPU-Ressourcen, einschränken kann.
• Numerische Verifizierung: Die Implementierung umfasst einen rigorosen Verifizierungsprozess, bei dem Energiewachstumsraten und 2D-Modenstrukturen gegen CPU-Ergebnisse verglichen werden, was bestätigt, dass die GPU-Version die Physik trotz geringfügiger numerischer Abweichungen durch compiler-spezifische Gleitkomma-Handhabung mit hoher Treue reproduziert.

Ergebnisse

• Speedup: Für eine realistische Arbeitslast von $32 \times 10^6$ Elektronen erreichte die GPU-Implementierung einen Speedup von etwa 14,8x auf dem AMD Viper-Knoten und 29,6x auf dem NVIDIA Pitagora-Knoten im Vergleich zur GCC-kompilierten CPU-Version auf dem TOK-Cluster.
• Kernel-Effizienz: Der Partikel-Pusher-Kernel machte den Großteil der Laufzeit aus. Das Profiling auf dem AMD MI300A zeigte eine hohe arithmetische Intensität mit L1/L2-Cache-Trefferquoten von über 80 %, obwohl nur 18 % der Speicherzugriffe koalesziert waren.
• Skalierbarkeitsbeschränkungen: Strong-Scaling-Tests zeigten, dass der GPU-beschleunigte Teil gut skaliert, der Gesamtanwendungsspeedup jedoch durch die nicht beschleunigten Teile (z. B. Feldlöser mittels PETSc) und den Overhead der Übersubskription von GPUs begrenzt wird. Auf dem NVIDIA Pitagora-Cluster wurde festgestellt, dass die Multi-GPU-Unterstützung via OpenMP in der getesteten Compiler-Version (nvfortran 24.9) nicht funktionsfähig war, was die Nutzung aller verfügbaren GPUs auf einem Knoten gleichzeitig einschränkt.
• Korrektheit: Simulationen des Cyclone-Falls (ITG-Mode) und des TCV-X21-Falls (nichtlineare ITG-Instabilität) bestätigten, dass die GPU-Version die beobachteten Energiewachstumsraten und Modenstrukturen der CPU-Version korrekt reproduziert; Unterschiede wurden der Initialisierung der Zufallszahlengeneratoren und compiler-spezifischen Gleitkomma-Variationen zugeschrieben und nicht algorithmischen Fehlern.

Bedeutung und Ansprüche
Das Paper behauptet, dass OpenMP-Offloading zwar einen vielversprechenden Weg für die Portabilität zwischen verschiedenen HPC-Architekturen bietet, es sich jedoch nicht um eine „nahtlose“ Lösung für komplexe Legacy-Codes handelt. Die Arbeit zeigt, dass das Erreichen einer funktionierenden, Hochleistungs-GPU-Version eine umfassende Exploration der Compiler und eine signifikante Code-Restrukturierung erfordert, um die aktuellen Einschränkungen der Compiler-Unterstützung für fortgeschrittene Fortran-Features zu umgehen.

Die Autoren betonen, dass der Erfolg dieser Portabilität stark von der spezifischen Compiler-Version abhängt und nicht nur vom Programmierparadigma. Sie kommen zu dem Schluss, dass die TRIMEG-GPU-Implementierung ein funktionales und akkurates Werkzeug für gyrokinetische Simulationen ist, das in der Lage ist, erhebliche Beschleunigungen für die rechenintensivsten Teile des Codes zu liefern. Sie merken jedoch bescheiden an, dass das volle Potenzial der Hardware (insbesondere Multi-GPU-Knoten) derzeit durch die unreife Compiler-Unterstützung für Multi-Device-Offloading und den Mangel an OpenMP-Multithreading in der zugrunde liegenden CPU-Codestruktur behindert wird. Die Arbeit dient als praktischer Leitfaden und „Surrogat-Dokumentation“ für andere, die eine ähnliche Portierung komplexer Fortran-Codes auf heterogene Architekturen anstreben.