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

Dit artikel presenteert de succesvolle porting van de TRIMEG gyrokinetische plasmasimulatiecode naar GPU-architecturen met behulp van de draagbare OpenMP API, waarbij significante versnellingen en geverifieerde fysische nauwkeurigheid worden aangetoond via hybride MPI-OpenMP parallellisatie en Ion Temperature Gradient mode simulaties.

De kern

Het Grote Plaatje: Een Kosmoze Storm Koken

Stel je voor dat je probeert het weer te voorspellen binnenin een ster. In de echte wereld kunnen we niet zomaar een thermometer in de zon of een fusiereactor steken; het is te heet en chaotisch. In plaats daarvan gebruiken wetenschappers supercomputers om "virtuele simulaties" van plasma (superheet, elektrisch geladen gas) uit te voeren.

De TRIMEG-code is een specifiek, zeer geavanceerd recept voor het simuleren van dit plasma. Het volgt miljarden kleine deeltjes (zoals individuele zandkorrels in een storm) om te zien hoe ze ronddraaien, botsen en turbulentie creëren. Het probleem? Dit recept is ontzettend zwaar. Het draaien op een standaardcomputer (CPU) is als het verplaatsen van een berg met een enkele lepel. Het duurt te lang.

Het Doel: De auteur, Giorgio Daneri, wilde dit versnellen door gebruik te maken van GPU's (Graphics Processing Units). Zie een CPU als een enkele meesterkok die erg slim is, maar slechts één groente tegelijk kan snijden. Een GPU is als een keuken met 10.000 sous-chefs die allemaal tegelijkertijd groenten kunnen snijden. De thesis gaat over het uitzoeken hoe je dat recept van de enkele meesterkok perfect werkend krijgt met een leger van 10.000 sous-chefs, en dat op een manier die werkt voor twee verschillende merken keukens (NVIDIA en AMD).

De Uitdaging: Het "Universele Vertaler"-probleem

De auteur koos een hulpmiddel genaamd OpenMP om de vertaling te doen. Zie OpenMP als een universele vertaler die tegen de computer zegt: "Hé, neem dit deel van het recept en geef het aan de GPU."

De auteur liep echter tegen twee grote hindernissen aan:

1. De "Compiler"-fout: De software die de code vertaalt (de compiler) was niet perfect. Het was alsoam een universele vertaler die soms vergeet hoe je "zout" of "hitte" zegt. De auteur moest delen van de code herschrijven om aan de eigenaardigheden van de vertaler te voldoen. Bijvoorbeeld: de code gebruikte geavanceerde "polymorfisme" (een chique manier om objecten te beschrijven die van vorm of identiteit kunnen veranderen). De vertalers (compilers) voor de GPU's begrepen deze vormverandering niet, dus moest de auteur de vormen platlaan tot rigide dozen om ze werkend te krijgen.
2. De "Verkeersopstopping": Het verplaatsen van gegevens tussen de hoofdcomputer (CPU) en de GPU (de sous-chefs) is traag. Als je steeds stopt om ingrediënten heen en weer te brengen, zitten de sous-chefs onnodig stil te wachten. De auteur moest de code zo herstructureren dat alle ingrediënten aan het begin één keer naar de GPU worden verplaatst, in plaats van ze constant heen en weer te pendelen.

De Oplossing: De Keuken Herstructureren

Om de code op zowel NVIDIA- als AMD-GPU's te laten draaien, moest de auteur enkele "operaties" uitvoeren op de TRIMEG-code:

• De Kaart Afvlakken: De code gebruikte een complexe kaart om te vinden waar deeltjes zich bevonden. Deze kaart was als een rommelige archiefkast. De auteur maakte deze plat tot een enkele, rechte lijst, zodat de GPU deze direct kon lezen zonder de weg kwijt te raken.
• De "Race" Fixen: Soms, wanneer duizenden sous-chefs tegelijkertijd op hetzelfde whiteboard proberen te schrijven, krabbelen ze over elkaar heen (een "race condition"). De auteur vond plekken waar de code dit deed en heeft het gefixt, zodat iedereen in zijn eigen baan schrijft.
• Het "One-Size-Fits-All" Compromis: Omdat de twee GPU-merken (NVIDIA en AMD) net iets andere talen spreken, moest de auteur een enkele codeversie maken die voor beide werkt, zelfs als dat betekende dat er gebruik moest worden gemaakt van enkele "workarounds" (zoals het gebruiken van een specifiek type geheugenallocatie dat voor beide werkt, ook al is het niet de absolute snelste voor de één).

De Resultaten: Heeft het Gewerkt?

De auteur testte de nieuwe GPU-versie tegen de oude CPU-versie met behulp van twee beroemde "testgevallen" (zoals standaard rijtests voor een nieuwe auto):

1. De Cycloon-case: Een vereenvoudigde simulatie van plasma-turbulentie.
2. De TCV-X21 Case: Een complexere, meer realistische simulatie die betrekking heeft op de rand van het plasma.

De Conclusie:

• Snelheid: De GPU-versie was aanzienlijk sneller. In sommige tests was het bijna 30 keer sneller dan de CPU-versie bij het draaien op één enkele machine.
• Nauwkeurigheid: De resultaten van de GPU kwamen bijna perfect overeen met de CPU-resultaten. De "weerpatronen" (energiegroei en turbulentiestructuren) zagen er hetzelfde uit.
• Draagbaarheid: De code draaide succesvol op zowel NVIDIA- als AMD-hardware zonder dat deze volledig opnieuw geschreven hoefde te worden.

De Adders onder het Gras (Beperkingen)

De auteur is eerlijk over de beperkingen:

• De "Vertaler" is nog niet perfect: De compilers (de software die code omzet in machinetaal) voor deze GPU's zijn nog volop in ontwikkeling. Soms produceren ze net iets andere wiskundige resultaten dan de CPU, wat na verloop van tijd voor minuscule fouten kan zorgen.
• Hardware Mismatch: Als je een computer hebt met veel CPU-kernen maar slechts één GPU, kan de GPU overbelast raken als je probeert het te veel taken tegelijk te voeren. De auteur ontdekte dat voor de beste resultaten een balans nodig is tussen hoeveel "chefs" (MPI-processen) je hebt versus hoeveel "sous-chefs" (GPU-threads) beschikbaar zijn.
• Geen "Magische Kogel": Hoewel het deel van de code dat deeltjes verplaatst een enorme snelheidswinst heeft geboekt, draaien andere delen van de simulatie (zoals het oplossen van de magnetische veldvergelijkingen) nog steeds op de CPU, omdat de tools om die specifieke delen naar de GPU te verplaatsen nog niet klaar zijn.

Samenvatting

Kortom, deze thesis is een verhaal van technisch vernuft. De auteur nam een zware, trage, complexe simulatiecode en slaagde erin deze te leren draaien op moderne, krachtige grafische kaarten. De auteur navigeerde door een mijnenveld van softwarebugs en compilerbeperkingen om een versie te creëren die werkt op twee verschillende soorten hardware, waarmee bewezen wordt dat we fusieplasma veel sneller kunnen simuleren zonder aan nauwkeurigheid in te boeten. Het is een cruciale stap naar het efficiënter maken van onderzoek naar fusie-energie, hoewel de reis naar een volledig geautomatiseerde, perfecte vertaling nog niet ten einde is.

Technische samenvatting

Technische Samenvatting: GPU-acceleratie en Portabiliteit van de TRIMEG-code voor Gyrokinetische Plasmasimulaties met OpenMP

Probleemstelling
Plasmaconstructies, met name gyrokinetische modellen die worden gebruikt voor het bestuderen van instabiliteiten en turbulentie in tokamak-fusieapparaten, zijn computationeel intensief. De TRIMEG-code, een hoog-nauwkeurige particle-in-cell (PIC) solver die gebruikmaakt van een C1-eindige-elementenmethode op ongestructureerde driehoekige meshes, staat voor aanzienlijke uitdagingen wat betreft de executietijd vanwege het enorme aantal deeltjes (vaak $10^7$ tot $10^8$) dat vereist is voor realistische simulaties. Hoewel de code al MPI gebruikt voor multi-node parallellisme, vormen de particle pushing en de grid-to-particle (G2P) operaties de primaire bottleneck en verbruiken zij tot 80% van de totale executietijd. De uitdaging ligt in het versnellen van deze specifieke "hotspots" met behulp van Graphics Processing Units (GPU's), terwijl de portabiliteit naar verschillende hardware-architecturen (specifiek NVIDIA en AMD) behouden blijft en de complexe objectgeoriënteerde structuur van de code — die polymorfisme en afgeleide types omvat — intact blijft.

Methodologie
De studie richt zich op het porteren van de TRIMEG-code naar GPU-architecturen met behulp van de OpenMP offloading API (versie 4.0 en later). De methodologie omvatte:

1. Target Selectie: De particle pusher kernel en de bijbehorende G2P-operaties (pullback, dichtheidsberekening en distributiefunctie-interpolatie) werden geïdentificeerd als de primaire doelwitten voor offloading vanwege hun hoge rekenintensiteit en gebrek aan interactie tussen deeltjes-afhankelijkheden.
2. Codestructurering voor Portabiliteit: Significante herstructurering was vereist om de beperkingen van compilers in zowel amdflang (AMD) als nvfortran (NVIDIA) te overwinnen. Belangrijke uitdagingen waren:
   • Polymorfisme: Beide compilers hadden moeite met class() afgeleide types en type-gebonden procedures binnen GPU target regio's. De oplossing bestond uit het herstructureren van de code door waar mogelijk non-polymorfe type() declaraties te gebruiken en een workaround te implementeren voor circulaire afhankelijkheden tussen deeltjes- en veldklassen door middel van base/extended klasse-hiërarchieën en Fortran INCLUDE-directives om functie-lichamen te dupliceren.
   • Dynamische Arrays: De code maakte gebruik van een aangepaste bibliotheek die C++ vectoren nabootst voor dynamische arrays. Omdat GPU-kernels niet gemakkelijk kunnen omgaan met dynamische allocatie of complexe pointer-indirecties, werd de mapping-structuur tussen bounding boxes en mesh-driehoeken "geflatten" van een array van structuren naar 1D-arrays om efficiënte geheugentransfers te faciliteren.
   • Geheugenbeheer: Pre-emptieve geheugenallocatie werd geïmplementeerd tijdens de initialisatiefase om runtime-latentie te minimaliseren. Voor AMD-platforms werd Unified Shared Memory (USM) ingezet waar mogelijk, terwijl voor NVIDIA-platforms zonder USM-ondersteuning expliciete enter data, update en exit data directives werden gebruikt.
   • Numerieke Consistentie: Om te garanderen dat de GPU-resultaten overeenkwamen met de CPU-referentie, werden compiler-optimalisaties die drijvende-kommagetallen-arithmetiek wijzigen (zoals Fused-Multiply-Add instructies) uitgeschakeld (-ffp-contract=off voor AMD, -Mnofma voor NVIDIA). Race conditions in de externe B-spline bibliotheek werden opgelost door over te schakelen van gedeelde objectleden naar lokaal verklaarde automatische arrays.
3. Prestatie-evaluatie: De implementatie werd getest op de Viper cluster (AMD MI300A), Raven (NVIDIA A100) en Pitagora (NVIDIA H100) clusters. Prestaties werden geëvalueerd via:
   • Kernel Profiling: Gebruik van rocprof-compute en nsys om resource bezetting, geheugenbandbreedte en instructie-mixen te analyseren.
   • Scalability Studies: Strong scaling tests werden uitgevoerd om de efficiëntie van hybride MPI-OpenMP offloading te beoordelen, waarbij specifiek gekeken werd naar de impact van het oversubscriben van GPU's met meerdere MPI-processen.
   • Grid Size Exploratie: Het afstemmen van het aantal OpenMP teams en threads per team om hardware-utilisatie te maximalen.

Belangrijkste Bijdragen

• Eerste Cross-Vendor Port: Dit werk vormt een pioniersinspanning in het porteren van een complexe, objectgeoriënteerde Fortran gyrokinetische code naar zowel NVIDIA- als AMD-GPU's via een enkele codebase met behulp van OpenMP offloading.
• Compiler Workarounds: De thesis documenteert specifieke, niet-triviale workarounds voor compiler-beperkingen met betrekking tot polymorfisme, dynamische arrays en procedure pointers in OpenMP target regio's. Het benadrukt het gebrek aan uitgebreide documentatie voor nvfortran en amdflang met betrekking tot deze functies.
• Hybride Parallelisatie Analyse: De studie biedt een gedetailleerde analyse van de trade-offs in hybride MPI-OpenMP offloading, en laat zien dat hoewel GPU-acceleratie effectief is voor de particle pusher, het gebrek aan OpenMP multithreading in de oorspronkelijke code noodzakelijke oversubscribing vereist, wat de schaalbaarheid op nodes met een hoog aantal cores maar beperkte GPU-resources kan beperken.
• Numerieke Verificatie: De implementatie bevat een rigoureus verificatieproces waarbij energie-groeisnelheden en 2D mode-structuren worden vergeleken met CPU-resultaten, wat bevestigt dat de GPU-versie de fysica met hoge getrouwheid reproduceert, ondanks kleine numerieke afwijkingen veroorzaakt door compiler-specifieke floating-point afhandeling.

Resultaten

• Speedup: Voor een realistische workload van $32 \times 10^6$ elektronen bereikte de GPU-implementatie een speedup van ongeveer 14.8x op de AMD Viper node en 29.6x op de NVIDIA Pitagora node vergeleken met de GCC-gecompileerde CPU-versie op de TOK cluster.
• Kernel Efficiëntie: De particle pusher kernel maakte het grootste deel van de runtime uit. Profiling op de AMD MI300A toonde een hoge rekenintensiteit met 80%+ L1/L2 cache hits, hoewel slechts 18% van de geheugentoegang gecoalesceerd was.
• Scalability Beperkingen: Strong scaling tests toonden aan dat hoewel het GPU-geaccelereerde deel goed schaalt, de algehele applicatie-speedup wordt beperkt door de niet-geaccelereerde delen (bijv. field solvers met PETSc) en de overhead van het oversubscriben van GPU's. Op de NVIDIA Pitagora cluster bleek de multi-GPU ondersteuning via OpenMP niet functioneel in de geteste compilerversie (nvfortran 24.9), wat het gebruik van alle beschikbare GPU's op een node tegelijkertijd beperkt.
• Correctheid: Simulaties van de Cyclone case (ITG mode) en de TCV-X21 case (niet-lineaire ITG instabiliteit) bevestigden dat de GPU-versie de energie-groeisnelheden en mode-structuren correct reproduceert die in de CPU-versie worden waargenomen, waarbij verschillen worden toegeschreven aan de initialisatie van de random number generator en compiler-specifieke floating-point variaties in plaats van algoritmische fouten.

Betekenis en Claims
Het artikel claimt dat hoewel OpenMP offloading een veelbelovend pad biedt voor portabiliteit tussen verschillende HPC-architecturen, het geen "naadloze" oplossing is voor complexe legacy-codes. Het werk demonstreert dat het bereiken van een werkende, hoog-presterende GPU-versie uitgebreide verkenning van compilers en significante codestructurering vereist om de beperkingen in de ondersteuning van geavanceerde Fortran-functies te omzeilen.

De auteurs benadrukken dat het succes van deze portabiliteit sterk afhangt van de specifieke compilerversie in plaats van enkel het programmeerparadigma. Zij concluderen dat de TRIMEG GPU-implementatie een functionele en nauwkeurige tool is voor gyrokinetische simulaties, in staat om aanzienlijke versnellingen te leveren voor de meest computationeel dure onderdelen van de code. Echter, zij merken bescheiden op dat het volledige potentieel van de hardware (met name multi-GPU nodes) momenteel wordt gehinderd door een onvolwassen compiler-ondersteuning voor multi-device offloading en het gebrek aan OpenMP multithreading in de onderliggende CPU-codestructuur. Het werk dient als een praktische gids en een "surrogaat-documentatie" voor anderen die vergelijkbare ports van complexe Fortran-codes naar heterogene architecturen proberen te uitvoeren.