🔬 physics

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

Questo articolo presenta un'accelerazione GPU basata su OpenMP e portabile del codice girocinetico elettromagnetico TRIMEG-C1 per architetture NVIDIA e AMD, dimostrando un'accelerazione di nove volte sulle APU AMD MI300A pur verificando la correttezza dell'implementazione attraverso simulazioni del modo del gradiente di temperatura ionica.

Autori originali: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Pubblicato 2026-06-24

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina un tokamak (un reattore a fusione nucleare a forma di ciambella) come una gigantesca e caotica cucina dove viene cucinato un plasma caldissimo. Per capire come si comporta questo plasma senza far fondere la pentola, gli scienziati usano un complesso programma per computer chiamato TRIMEG-C1. Questo programma simula miliardi di minuscole particelle invisibili (come chef microscopici) che si muovono, si scontrano tra loro e creano onde di energia.

Per molto tempo, questa simulazione è stata eseguita su processori standard (CPU). Era accurata, ma anche incredibilmente lenta — come cercare di cucinare un banchetto per un milione di persone usando solo un singolo, lentissimo cucchiaio.

Questo articolo parla di come gli ricercatori abbiano dato a quel cucchiaio un potenziamento super: le Unità di Elaborazione della Grafica (GPU). Le GPU sono gli stessi chip presenti nelle console per videogiochi, ma sono progettate per fare migliaia di calcoli contemporaneamente, il che le rende perfette per simulare milioni di particelle simultaneamente.

Ecco la storia di come i ricercatori hanno aggiornato il codice, gli ostacoli che hanno affrontato e i risultati ottenuti.

1. La Sfida: Parlare Due Lingue Contemporaneamente

I ricercatori volevano che il loro codice girasse su due diversi tipi di "super-chef" (GPU):

NVIDIA: Il leader dominante nel mercato (come un famoso e costoso marchio di attrezzature da cucina).
AMD: Un concorrente emergente, più economico e sempre più comune nei supercomputer.

Il problema? Il codice era scritto in Fortran, un linguaggio vecchio ma potente per la scienza. La maggior parte degli strumenti per far girare il codice Fortran sulle GPU era progettata specificamente per NVIDIA. Se avessero usato quegli strumenti, il codice si sarebbe rotto sulle macchine AMD. Se avessero scritto versioni separate per ciascuna, avrebbero dovuto mantenere due diversi database di codice, il che è un incubo per gli sviluppatori di software.

La Soluzione: Hanno scelto uno strumento chiamato OpenMP. Pensa a OpenMP come a un traduttore universale. Permette agli scienziati di scrivere un unico set di istruzioni che dice: "Esegui questo calcolo sulla GPU", e il computer capisce come tradurre questo nel linguaggio specifico di un chip NVIDIA o AMD.

2. Gli Ostacoli: Strade Acciottolate sull'Autostrada

Sebbene OpenMP fosse la scelta giusta per la portabilità, la strada non è stata liscia. I ricercatori hanno incontrato diversi "punti critici" causati dal fatto che i compilatori (i programmi che traducono il codice in linguaggio macchina) per queste GPU erano ancora nella loro "prima infanzia".

Il Problema della "Scatola Nera": Il codice faceva affidamento su una libreria (una cassetta degli attrezzi pre-confezionata) per eseguire calcoli complessi chiamati "interpolazione B-spline". Questa libreria utilizzava funzioni avanzate che i compilatori delle GPU non comprendevano ancora appieno. I ricercatori hanno dovuto riscrivere manualmente parti di questa cassetta degli attrezzi per renderla compatibile, essenzialmente ricostruendo il motore mentre l'auto era ancora in movimento.
La Perdita di Memoria (Memory Leak): Su un tipo di GPU (NVIDIA), il codice improvvisamente si bloccava dopo un certo periodo di esecuzione. Si è rivelato essere una "race condition" (condizione di corsa) — immagina due chef che cercano di afferrare lo stesso ingrediente esattamente nello stesso momento, causando un blocco. I ricercatori hanno dovuto trovare e correggere questo bug invisibile.
La Cucina "Sovraffollata": Quando provavano a eseguire troppe simulazioni contemporaneamente su una singola GPU, la memoria finiva. Hanno dovuto riorganizzare il modo in cui i dati venivano memorizzati (appiattendoli da strutture complesse in semplici liste) in modo che la GPU non venisse sopraffatta.

3. I Risultati: Un Demone della Velocità

Una volta corretti i bug e ottimizzato il codice, i risultati sono stati impressionanti.

La Spinta di Velocità: Su un particolare supercomputer AMD (il cluster "Viper"), la nuova versione GPU della simulazione delle particelle era 9 volte più veloce della vecchia versione CPU. Su una macchina NVIDIA di fascia alta (il cluster "Pitagora"), era anch'essa significativamente più veloce.
Il Test di "Oversubscription": Di solito, si vuole che una GPU gestisca un solo compito. Ma nei veri supercomputer, le risorse sono scarse. I ricercatori hanno testato cosa succede se si costringono più attività a condividere una singola GPU. Sorprendentemente, il codice ha retto bene, dimostrando di poter essere comunque efficiente anche quando la GPU stava facendo il gioco di prestigio con più lavori contemporaneamente.
Controllo dell'Accuratezza: La velocità è inutile se i risultati sono sbagliati. Per dimostrare che la versione GPU fosse affidabile, hanno eseguito due famosi casi di test:
1. Il Caso del Ciclone: Un modello semplificato di instabilità del plasma. I risultati della GPU corrispondevano quasi perfettamente ai risultati della CPU (entro un margine d'errore minuscolo, dovuto principalmente alla natura casuale della simulazione).
2. Il Caso TCV: Un modello più realistico e complesso di un vero reattore a fusione. Anche in questo caso, la versione GPU ha riprodotto correttamente la fisica, catturando la crescita delle onde di energia e la forma del plasma.

4. La Conclusione

L'articolo conclude che hanno costruito con successo una versione portabile di un complesso codice fisico. È come creare un telecomando universale che funziona sia su Samsung che su LG senza dover comprare due telecomandi diversi.

Cosa hanno ottenuto: Hanno reso una lenta simulazione basata su CPU 9 volte più veloce su moderne GPU, e funziona su entrambi i principali marchi di hardware (NVIDIA e AMD).
Cosa non hanno fatto: Non hanno inventato nuova fisica né hanno risolto la crisi energetica. Hanno semplicemente dimostrato che il coltello usato per studiare la fusione è ora molto più veloce e flessibile.

In breve, i ricercatori hanno preso una simulazione scientifica pesante e lenta, le hanno dato un turbo (le GPU) e si sono assicurati che il turbo funzioni su qualsiasi marca di motore, aprendo la strada a studi più veloci e dettagliati su come un giorno potremmo sfruttare l'energia delle stelle.

Sintesi Tecnica: Accelerazione GPU tramite OpenMP e Portabilità di TRIMEG-C1 per Simulazioni Girocinetiche Elettromagnetiche

Definizione del Problema
Il codice TRIMEG-C1 è un solver particle-in-cell (PIC) girocinetico basato su mesh triangolari, progettato per simulare instabilità elettromagnetiche nei plasmi tokamak. Utilizza un metodo a elementi finiti di ordine superiore $C^1$ per catturare una fisica accurata con una risoluzione di griglia inferiore rispetto ai metodi $C^0$ . Tuttavia, poiché i supercomputer moderni si affidano sempre più ad architetture eterogenee, il codice affronta la sfida di scalare verso simulazioni multi-scala che coinvolgono piccole scale elettroniche e scale temporali di trasporto. Sebbene l'offloading su GPU offra un significativo potenziale di accelerazione per i codici PIC grazie alla loro alta parallelizzazione, gli approcci esistenti spesso mancano di portabilità. OpenACC, utilizzato in codici come GEM e ORB5, è ben supportato sulle architetture NVIDIA, ma manca di un robusto supporto per le GPU AMD, sempre più diffuse nei cluster per l'High-Performance Computing (HPC) (ad esempio, il cluster Viper della Max Planck Computing and Data Facility). Al contrario, CUDA o HIP richiedono una riscrittura significativa del codice o una manuale traduzione dei kernel. Il problema principale affrontato è il raggiungimento di un'implementazione accelerata e portabile di TRIMEG-C1 sia su architetture GPU NVIDIA che AMD, senza compromettere la struttura esistente del codice Fortran o richiedere un'estesa duplicazione del codice.

Metodologia
Gli autori hanno selezionato il framework di offloading OpenMP come strategia di accelerazione. Questa scelta è stata guidata dalla sua capacità di supportare sia GPU NVIDIA che AMD all'interno di un codice Fortran unificato, minimizzando le modifiche strutturali e la divergenza del codice. Il processo di porting si è concentrato sulle componenti computazionalmente più intensive: il kernel del "particle pusher" e le operazioni di grid-to-particle (G2P) (incluse il trattamento di pullback, il calcolo della densità e l'interpolazione della funzione di distribuzione).

Le fasi metodologiche chiave hanno incluso:

Adattamento dei Kernel: Il particle pusher, che evolve le particelle marker indipendentemente, è stato avvolto in una singola grande regione target OpenMP per massimizzare il parallelismo. Ciò ha richiesto la rifattorizzazione del codice per garantire che tutte le funzioni chiamate, incluse quelle provenienti da una libreria esterna di interpolazione B-spline, fossero invocabili dal dispositivo (device-callable).
Soluzioni per i Limiti dei Compilatori: Un impegno significativo è stato dedicato al superamento delle limitazioni dei compilatori amdflang e nvfortran riguardo all'offloading OpenMP. Le sfide specifiche hanno incluso:
- Polimorfismo e Procedure Associate al Tipo (Type-Bound Procedures): Né il compilatore né l'altro supportano pienamente queste caratteristiche nel codice device. Gli autori hanno modificato il codice per utilizzare dichiarazioni di type non polimorfiche invece di class dove necessario, ed hanno bypassato i legami delle procedure associate al tipo nella libreria B-spline.
- Gestione della Memoria: Per gestire array dinamici che mimano il std::vector del C++, gli autori hanno appiattito i layout dei dati Array-of-Structures (AoS) in array monodimensionali per evitare problemi complessi di mappatura dei puntatori a runtime e l'errore Out-Of-Memory (OOM) sulle APU AMD MI300A.
- Race Condition: Una race condition nell'uso di array temporanei condivisi nella libreria B-spline è stata risolta passando a array automatici dichiarati localmente.
- Ottimizzazione delle Prestazioni: Su GPU NVIDIA, il kernel ha inizialmente subito un degrado delle prestazioni dovuto all'allocazione a runtime di array temporanei. Ciò è stato mitigato passando ad array a dimensione fissa stabilita a tempo di compilazione per funzioni specifiche, una modifica applicata condizionalmente in base all'architettura target.
Parallelismo Ibrido: Lo studio ha valutato una strategia di parallelizzazione ibrida MPI-OpenMP, analizzando le prestazioni sotto sovra-allocazione delle risorse (esecuzione di più processi MPI per GPU) per determinare la fattibilità per simulazioni su larga scala dove l'allocazione dei nodi è limitata.

Contributi Chiave

Implementazione GPU Portabile: Il documento presenta il primo porting riuscito del codice TRIMEG-C1 su entrambe le architetture GPU NVIDIA e AMD utilizzando OpenMP, consentendo l'esecuzione su diversi sistemi HPC (ad esempio, Viper, Raven, Pitagora).
Risoluzione delle Sfide Specifiche dei Compilatori: Il lavoro dettaglia i workaround specifici per le limitazioni dei compilatori Fortran nell'offloading OpenMP, in particolare riguardo al polimorfismo, l'allocazione dinamica della memoria e l'integrazione di librerie esterne.
Benchmarking delle Prestazioni: Sono state condotte valutazioni complete delle prestazioni su molteplici cluster (AMD MI300A, NVIDIA A100, NVIDIA H100) e dimensioni dei problemi, analizzando sia gli speedup dei singoli kernel che la scalabilità forte.
Validazione: La correttezza dell'implementazione GPU è stata rigorosamente verificata rispetto ai risultati CPU utilizzando casi di benchmark standard, garantendo che il processo di porting non introducesse imprecisioni fisiche.

Risultati

Speedup: Per una dimensione del problema realistica di $32 \times 10^6$ particelle marker su un nodo completo, il kernel del particle pusher ha ottenuto uno speedup di circa 9x sia su AMD MI300A (Viper) che su NVIDIA H100 (Pitagora) rispetto alla più veloce implementazione solo CPU (AMD EPYC 9754).
Sovra-allocazione (Oversubscription): Lo studio ha rilevato che, sebbene la sovra-allocazione delle risorse GPU (aumento dei processi MPI per nodo) riduca lo speedup dei singoli kernel a causa della serializzazione e del context switching, l'approccio ibrido rimane vitale. Tuttavia, lo speedup complessivo del codice dipende fortemente dalla dimensione del carico di lavoro; per carichi minori ( $10^6$ particelle), il vantaggio diminuisce significativamente rispetto a un nodo solo CPU a causa dell'overhead di trasferimento dati e della limitata intensità aritmetica.
Scalabilità: L'analisi della scalabilità forte ha dimostrato che il codice accelerato tramite GPU scala bene su più nodi, sebbene il guadagno di prestazioni complessivo sia marginale quando la fase particle-to-grid (P2G) domina, poiché questa fase beneficia significativamente dell'alto numero di core dei nodi solo CPU.
Correttezza: I confronti delle simulazioni del modo del gradiente di temperatura ionica (ITG) per entrambi i casi Cyclone e TCV-X21 hanno mostrato un buon accordo tra le versioni CPU e GPU. I tassi di crescita dell'energia differivano di meno del 3% per il caso Cyclone e generalmente al di sotto del 10% per il caso TCV-X21 (con deviazioni maggiori per numeri di modo toroidale più elevati). Anche le strutture modali bidimensionali sono state preservate.
Profiling: Il profiling su GPU AMD ha rivelato un'alta pressione sui registri che limita le unità di calcolo (CU) attive e un basso utilizzo della Local Data Share (LDS), attribuito all'incapacità dell'API OpenMP di gestire esplicitamente la memoria condivisa.

Significatività e Rivendicazioni
Il documento afferma che il porting riuscito di TRIMEG-C1 alle architetture GPU tramite OpenMP fornisce una base computazionale portabile per futuri studi fisici su larga scala. Gli autori sottolineano che, sebbene l'implementazione abbia richiesto una significativa ristrutturazione del codice per navigare le limitazioni dei compilatori, il codice risultante consente la simulazione di instabilità elettromagnetiche su diverse piattaforme hardware senza dover mantenere codebase separate per diversi vendor.

Il lavoro stabilisce che il particle pusher è il candidato primario per l'accelerazione GPU, producendo speedup sostanziali per grandi conteggi di particelle. Tuttavia, gli autori notano con modestia che le prestazioni complessive del codice sono attualmente limitate da altre fasi (come la risoluzione delle equazioni di campo e le operazioni P2G) che sono meno adatte all'accelerazione GPU o che beneficiano maggiormente del parallelismo CPU. Di conseguenza, il pieno potenziale dell'accelerazione GPU si realizza in simulazioni con grandi conteggi di particelle dove il pusher domina il tempo di esecuzione.

Il lavoro futuro, come delineato dagli autori, include l'integrazione di solver abilitati alla GPU tramite PETSc, l'esplorazione di un porting in C++ di TRIMEG per migliorare l'efficienza dell'offloading e ridurre l'impegno di porting, e l'implementazione dell'offloading GPU per le operazioni particle-to-grid. L'attuale versione accelerata tramite GPU di TRIMEG-C1 è posizionata come un passo intermedio verso studi sulla turbolenza multi-scala e indagini sul trasporto del plasma in configurazioni tokamak divertore realistiche.

1. La Sfida: Parlare Due Lingue Contemporaneamente

2. Gli Ostacoli: Strade Acciottolate sull'Autostrada

3. I Risultati: Un Demone della Velocità

4. La Conclusione

Articoli simili