🔬 physics

OpenMP GPU Acceleration and Portability of TRIMEG-C1 for Electromagnetic Gyrokinetic Simulations in Tokamak Plasmas

Dit artikel presenteert een draagbare OpenMP-gebaseerde GPU-versnelling van de TRIMEG-C1 elektromagnetische gyrokinetische code voor NVIDIA- en AMD-architecturen, waarbij een versnelling van negenvoudig wordt aangetoond op AMD MI300A APU's, terwijl de correctheid van de implementatie wordt geverifieerd door middel van Ion Temperature Gradient-modus simulaties.

Oorspronkelijke auteurs: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Gepubliceerd 2026-06-24

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een tokamak (een donutvormige kernfusiereactor) voor als een gigantische, chaotische keuken waar superheet plasma wordt bereid. Om te begrijpen hoe dit plasma zich gedraagt zonder de pan te doen smelten, gebruiken wetenschappers een complex computerprogramma genaamd TRIMEG-C1. Dit programma simuleert miljarden kleine, onzichtbare "deeltjes" (zoals microscopische chefs) die rondbewegen, tegen elkaar botsen en golven van energie creëren.

Lama tijd draaide deze simulatie op standaard computerprocessoren (CPU's). Het was accuraat, maar ook ongelooflijk traag—alsof je probeert een feestmaal voor een miljoen mensen te bereiden met slechts één enkele, zeer langzame lepel.

Dit artikel gaat over het geven van een superkracht-upgrade aan die lepel: Graphics Processing Units (GPU's). GPU's zijn dezelfde chips die in spelcomputers voor videogames zitten, maar ze zijn gebouwd om duizenden berekeningen tegelijkertijd uit te voeren, wat hen perfect maakt voor het gelijktijdig simuleren van miljoenen deeltjes.

Dit is het verhaal van hoe de onderzoekers de code hebben geüpgraded, de hindernissen die ze tegenkwamen en de resultaten die ze hebben behaald.

1. De Uitdaging: Twee Talen Tegelijk Spreken

De onderzoekers wilden hun code laten draaien op twee verschillende soorten "super-chefs" (GPU's):

NVIDIA: De dominante speler op de markt (zoals een beroemd, duur merk keukenapparatuur).
AMD: Een opkomende concurrent die goedkoper is en steeds vaker voorkomt in supercomputers.

Het probleem? De code was geschreven in Fortran, een oude maar krachtige taal voor wetenschappen. De meeste tools om Fortran-code op GPU's te laten draaien, waren specifiek ontworeld voor NVIDIA. Als ze die tools gebruikten, zou de code op AMD-machines kapot gaan. Als ze aparte versies voor elk type zouden schrijven, zouden ze twee verschillende codebases moeten onderhouden, wat een nachtmerrie is voor softwareontwikkelaars.

De Oplossing: Ze kozen voor een tool genaamd OpenMP. Zie OpenMP als een universele vertaler. Het stelt de wetenschappers in staat om één set instructies te schrijven die zegt: "Voer deze berekening uit op de GPU," en de computer begrijpt hoe hij dat moet vertalen naar de specifieke taal van ofwel een NVIDIA- of een AMD-chip.

2. De Hindernissen: Hobbelige Wegen op de Snelweg

Hoewel OpenMP de juiste keuze was voor draagbaarheid, was de weg niet zonder problemen. De onderzoekers stuitten op verschillende "kuilen" veroorzaakt door het feit dat de compilers (de programma's die code vertalen naar machinetaal) voor deze GPU's nog in hun "vroege kindertijd" verkeerden.

Het "Black Box"-proble𝓷: De code vertrouwde op een bibliotheek (een kant-en-klare gereedschapskist) voor het uitvoeren van complexe wiskunde genaamd "B-spline interpolatie". Deze bibliotheek gebruikte geavanceerde functies die de GPU-compilers nog niet volledig begrepen. De onderzoekers moesten delen van deze gereedschapskist handmatig herschrijven om ze compatibel te maken, wat neerkwam op het herbouwen van de motor terwijl de auto nog bewoog.
Het Geheugenlek: Op één type GPU (NVIDIA) bevroor de code plotseling na verloop van tijd. Het bleek een "race condition" te zijn—stel je voor dat twee chefs precies op hetzelfde moment naar hetzelfde ingrediënt proberen te grijpen, wat een blokkade veroorzaakt. De onderzoekers moesten deze onzichtbare bug opsporen en oplossen.
De "Overvolle" Keuken: Wanneer ze probeerden te veel simulaties tegelijkert op een enkele GPU te draaien, raakte het geheugen vol. Ze moesten de manier waarop gegevens werden opgeslagen reorganiseren (complexe structuren platmaken tot eenvoudige lijsten) zodat de GPU niet overbelast raakte.

3. De Resultaten: Een Snelheidsduivel

Zodra de bugs waren opgelost en de code was geoptimaliseerd, waren de resultaten indrukwekkend.

De Snelheidsboost: Op een specifieke AMD-supercomputer (de "Viper" cluster) was de nieuwe GPU-versie van de deeltjessimulatie 9 keer sneller dan de oude CPU-versie. Op een hoogwaardige NVIDIA-machine (de "Pitagora" cluster) was het ook aanzienlijk sneller.
De "Oversubscription"-test: Normaal gesproken wil je dat één GPU één taak afhandelt. Maar in echte supercomputing zijn middelen schaars. De onderzoekers testten wat er gebeurt als ze meerdere taken dwingen om één GPU te delen. Verrassend genoeg hield de code het goed stand, wat aantoonde dat het nog steeds efficiënt kon zijn, zelfs wanneer de GPU meerdere taken tegelijk moest jongleren.
Nauwkeurigheidscontrole: Snelheid is nutteloos als de resultaten fout zijn. Om te bewijzen dat de GPU-versie betrouwbaar was, draaiden ze twee beroemde testgevallen:
1. De Cyclone Case: Een vereenvoudigd model van plasma-instabiliteit. De GPU-resultaten kwamen bijna perfect overeen met de CPU-resultaten (binnen een minuscule foutmarge, voornamelijk door de willekeurige aard van de simulatie).
2. De TCV Case: Een realistischer, complexer model van een echte fusiereactor. Opnieuw reproduceerde de GPU-versie de fysica correct, waarbij de groei van energiegolven en de vorm van het plasma nauwkeurig werden vastgelegd.

4. De Conclusie

Het artikel concludeert dat ze succesvol een draagbare versie van een complexe natuurkundige code hebben gebouwd. Het is alsof je een universele afstandsbediening maakt die op zowel Samsung als LG tv's werkt zonder dat je twee verschillende afstandsbedieningen hoeft te kopen.

Wat ze hebben bereikt: Ze hebben een trage, op CPU gebaseerde simulatie veel sneller laten draaien op moderne GPU's, en het werkt op beide grote hardwaremerken (NVIDIA en AMD).
Wat ze niet hebben gedaan: Ze hebben geen nieuwe natuurkunde uitgevonden of de energiecrisis nog opgelost. Ze hebben simpelweg bewezen dat het instrument dat wordt gebruikt om fusie te bestuderen, nu veel sneller en flexibeler is.

Kortom, de onderzoekers hebben een zware, traag bewegende wetenschappelijke simulatie genomen, er een turbocharger (GPU's) aan gegeven en ervoor gezorgd dat de turbocharger op elk merk motor werkt, wat de weg vrijmaakt voor snellere en gedetailleerdere studies naar hoe we ooit de kracht van de sterren kunnen beheersen.

Technische Samenvatting: OpenMP GPU-acceleratie en Portabiliteit van TRIMEG-C1 voor Elektromagnetische Gyrokinetische Simulaties

Probleemstelling
De TRIMEG-C1 code is een op driehoeksmeshes gebaseerde gyrokinetische particle-in-cell (PIC) solver, ontworpen voor het simuleren van elektromagnetische instabiliteiten in tokamak-plasma's. De code maakt gebruik van een hogere-orde $C^1$ eindige-elementenmethode om nauwkeurige fysica te vangen met een lagere roosterresolutie vergeleken met $C^0$ -methoden. Echter, naarmate moderne supercomputers steeds meer afhankelijk worden van heterogene architecturen, staat de code voor de uitdaging om te schalen naar multi-schaal simulaties die zowel kleine elektronische schalen als transporttijdschalen omvatten. Hoewel GPU-offloading een aanzienlijk acceleratiepotentieel biedt voor PIC-codes vanwege hun hoge parallellisme, missen bestaande benaderingen vaak portabiliteit. OpenACC, gebruikt in codes zoals GEM en ORB5, wordt goed ondersteund op NVIDIA-architecturen, maar mist robuuste ondersteuning voor AMD GPU's, die steeds vaker voorkomen in High-Performance Computing (HPC) clusters (bijv. de Viper-cluster van de Max Planck Computing and Data Facility). Daarentegen vereisen CUDA of HIP aanzienlijke herschrijving van de code of handmatige kerneltranslatie. Het primaire probleem dat wordt aangepakt, is het bereiken van een draagbare, versnelde implementatie van TRIMEG-C1 op zowel NVIDIA als AMD GPU-architecturen zonder de bestaande Fortran-codebase structuur aan te tasten of uitgebreide code-duplicatie te vereisen.

Methodologie
De auteurs kozen voor het OpenMP offloading-framework als de acceleratiestrategie. Deze keuze werd gedreven door het vermogen om zowel NVIDIA als AMD GPU's te ondersteunen binnen een verenigde Fortran-codebase, waardoor structurele wijzigingen en code-divergentie worden geminimaliseerd. Het portingsproces richtte zich op de meest rekenintensieve componenten: de particle pusher kernel en de grid-to-particle (G2P) operaties (inclusief pullback-behandeling, dichtheidsberekening en distributiefunctie-interpolatie).

Belangrijke methodologische stappen omvatten:

Kernel Adaptatie: De particle pusher, die marker-deeltjes onafhankelijk evolueert, werd ingekapseld in een enkele grote OpenMP target regio om parallellisme te maximalen. Dit vereiste het herstructureren van de code om ervoor te zorgen dat alle aangeroepen functies, inclusief die van een externe B-spline interpolatiebibliotheek, device-callable waren.
Workarounds voor Compilerbeperkingen: Er werd aanzienlijke inspanning geleverd om de beperkingen van de amdflang en nvfortran compilers met betrekking tot OpenMP offloading te overwinnen. Specifieke uitdagingen omvatten:
- Polymorfisme en Type-Bound Procedures: Noch de ene, noch de andere compiler ondersteunt deze functies volledig in device code. De auteurs hebben de code aangepast door non-polymorfe type declaraties te gebruiken in plaats van class waar nodig, en de type-bound procedure bindingen in de B-spline bibliotheek te omzeilen.
- Geheugenbeheer: Om dynamische arrays te hanteren die C++ std::vector nabootsen, hebben de auteurs de Array-of-Structures (AoS) datalayouts platgeslagen naar eendimensionale arrays om complexe runtime pointer mapping problemen en Out-Of-Memory (OOM) fouten op AMD MI300A APU's te vermijden.
- Race Conditions: Een race condition in het gebruik van gedeelde tijdelijke arrays in de B-spline bibliotheek werd opgelost door over te schakelen naar lokaal gedeklareerde automatische arrays.
- Prestatieoptimalisatie: Op NVIDIA GPU's leed de kernel aanvankelijk aan prestatievermindering door runtime allocatie van tijdelijke arrays. Dit werd gemitigeerd door over te schakelen naar compile-time fixed-size arrays voor specifieke functies, een wijziging die conditioneel werd toegepast op basis van de doelarchitectuur.
Hybride Parallelisatie: De studie evalueerde een hybride MPI-OpenMP offloading strategie, waarbij de prestaties onder resource oversubscription (het draaien van meerdere MPI-processen per GPU) werden beoordeeld om de haalbaarheid voor grootschalige simulaties waarbij node-allocatie beperkt is, te bepalen.

Kernbijdragen

Draagbare GPU Implementatie: Het artikel presenteert de eerste succesvolle port van de TRIMEG-C1 code naar zowel NVIDIA als AMD GPU-architecturen met behulp van OpenMP, wat uitvoering op diverse HPC-systemen (bijv. Viper, Raven, Pitagora) mogelijk maakt.
Resolutie van Compiler-specifieke Uitdagingen: Het werk beschrijft specifieke workarounds voor Fortran compilerbeperkingen in OpenMP offloading, met name met betrekking tot polymorfisme, dynamische geheugenallocatie en externe bibliotheekintegratie.
Prestatie Benchmarking: Uitgebreide prestatie-evaluaties werden uitgevoerd over meerdere clusters (AMD MI300A, NVIDIA A100, NVIDIA H100) en probleemgroottes, waarbij zowel individuele kernel speedups als sterke schaalbaarheid werden geanalyseerd.
Validatie: De correctheid van de GPU-implementatie werd rigoureus geverifieerd tegen CPU-resultaten met behulp van standaard benchmark-cases, om te garanderen dat het portingsproces geen fysieke onnauwkeurigheden heeft geïntroduceerd.

Resultaten

Speedup: Voor een realistische probleemgrootte van $32 \times 10^6$ marker-deeltjes op een volledige node, bereikte de particle pusher kernel een speedup van ongeveer 9x op zowel de AMD MI300A (Viper) als de NVIDIA H100 (Pitagora) vergeleken met de snelste CPU-only implementatie (AMD EPYC 9754).
Oversubscription: De studie toonde aan dat hoewel het oversubscriben van GPU-resources (het verhogen van het aantal MPI-processen per node) de speedup van individuele kernels vermindert door serialisatie en context switching, de hybride aanpak nog steeds levensvatbaar is. De algehele codesnelheid is echter sterk afhankelijk van de workload grootte; voor kleinere workloads ( $10^6$ deeltjes) neemt het voordeel aanzienlijk af wanneer men wordt vergeleken met een volledig benutte CPU-node vanwege data transfer overhead en beperkte rekenintensiteit.
Schaalbaarheid: Sterke schaalingsanalyse toonde aan dat de GPU-geaccelereerde code goed schaalt over meerdere nodes, hoewel de algehele prestatiewinst marginaal is wanneer de particle-to-grid (P2G) fase domineert, aangezien deze fase aanzienlijk profiteert van het hoge aantal cores van CPU-only nodes.
Correctheid: Vergelijkingen van de Ion Temperature Gradient (ITG) mode simulaties voor zowel de Cyclone base case als de TCV-X21 case toonden een goede overeenkomst tussen de CPU en GPU versies. Energie groeicijfers verschilden met minder dan 3% voor de Cyclone case en over het algemeen onder de 10% voor de TCV-X21 case (met hogere afwijkingen bij hogere toroidale mode getallen). Tweidimensionale mode structuren werden eveneens behouden.
Profiling: Profiling op AMD GPU's onthulde een hoge register pressure die actieve Compute Units (CUs) beperkt en een laag gebruik van de Local Data Share (LDS), toegeschreven aan het onvermogen van de OpenMP API om shared memory expliciet te beheren.

Betekenis en Claims
Het artikel claimt dat de succesvolle porting van TRIMEG-C1 naar GPU-architecturen met behulp van OpenMP een draagbare computationele fundering biedt voor toekomstige grootschalige fysica-studies. De auteurs benadrukken dat hoewel de implementatie aanzienlijke code herstructurering vereiste om compilerbeperkingen te navigeren, de resulterende code het mogelijk maakt om elektromagnetische instabiliteiten op diverse hardwareplatforms te simuleren zonder aparte codebases voor verschillende leveranciers te onderhouden.

Het werk stelt vast dat de particle pusher de primaire kandidaat is voor GPU-acceleratie, wat substantiële speedups oplevert voor grote aantallen deeltjes. De auteurs merken echter bescheiden op dat de algehele code-prestaties momenteel worden beperkt door andere fasen (zoals het oplossen van veldvergelijkingen en P2G operaties) die minder geschikt zijn voor GPU-acceleratie of meer profiteren van CPU-parallellisme. Bijgevolg wordt het volledige potentieel van de GPU-acceleratie gerealiseerd in simulaties met grote aantallen deeltjes waar de pusher de runtime domineert.

Toekomstig werk, zoals geschetst door de auteurs, omvat het integreren van GPU-enabled solvers via PETSc, het verkennen van een C++ port van TRIMEG om de offloading efficiëntie te verbeteren en de porting inspanning te verminderen, en het implementeren van GPU offloading voor particle-to-grid operaties. De huidige GPU-geaccelereerde TRIMEG-C1 is gepositioneerd als een stapsteen naar multi-schaal turbulentie studies en onderzoek naar plasma transport in realistische gediverteerde tokamak configuraties.

1. De Uitdaging: Twee Talen Tegelijk Spreken

2. De Hindernissen: Hobbelige Wegen op de Snelweg

3. De Resultaten: Een Snelheidsduivel

4. De Conclusie

Meer zoals dit