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

Questo articolo presenta il porting riuscito del codice di simulazione del plasma girocinetico TRIMEG su architetture GPU utilizzando l'API portabile OpenMP, dimostrando accelerazioni significative e una precisione fisica verificata attraverso la parallelizzazione ibrida MPI-OpenMP e simulazioni del modo del gradiente di temperatura ionica.

L'essenziale

Il Quadro Generale: Cucinare una Tempesta Cosmica

Immaginate di cercare di prevedere il meteo all'interno di una stella. Nel mondo reale, non possiamo semplicemente infilare un termometro dentro il sole o un reattore a fusione; è troppo caldo e caotico. Invece, gli scienziati usano supercomputer per eseguire "simulazioni virtuali" del plasma (un gas super-caldo ed elettricamente carico).

Il codice TRIMEG è una ricetta specifica, molto sofisticata, per simulare questo plasma. Traccia miliardi di minuscole particelle (come singoli granelli di sabbia in una tempore) per vedere come ruotano, si scontrano e creano turbolenza. Il problema? Questa ricetta è incredibilmente pesante. Eseguirla su un computer standard (CPU) è come cercare di spostare una montagna con un singolo cucchiaio. Ci vuole troppo tempo.

L'Obiettivo: L'autore, Giorgio Daneri, voleva velocizzare questo processo utilizzando le GPU (Graphics Processing Units). Pensate alla CPU come a un singolo chef magistrale che è molto intelligente ma può tagliare solo una verdura alla volta. Una GPU è come una cucina con 10.000 chef di linea che possono tagliare le verdure simultaneamente. La tesi riguarda il modo per far sì che la ricetta di quel singolo chef magistrale funzioni perfettamente con un esercito di 10.000 chef di linea, e di farlo in un modo che funzioni per due diversi marchi di cucine (NVIDIA e AMD).

La Sfida: Il Problema del "Traduttore Universale"

L'autore ha scelto uno strumento chiamato OpenMP per fare la traduzione. Pensate a OpenMP come a un traduttore universale che dice al computer: "Ehi, prendi questa parte della ricetta e consegnala alla GPU".

Tuttavia, l'autore si è imbattuto in due ostacoli principali:

1. Il Glitch del "Compilatore": Il software che traduce il codice (il compilatore) non era perfetto. Era come cercare di usare un traduttore universale che a volte dimentica come si dice "sale" o "calore". L'autore ha dovuto riscrivere parti del codice per adattarsi alle stranezze del traduttore. Ad esempio, il codice utilizzava il "polimorfismo" avanzato (un modo elegante per dire oggetti che possono cambiare forma o identità). I traduttori (compilatori) per le GPU non capivano questo mutare di forma, quindi l'autore ha dovuto appiattire le forme in scatole rigide per farle funzionare.
2. Il "Ingorgo Stradale": Spostare i dati tra il computer principale (CPU) e la GPU (gli chef di linea) è lento. Se continui a fermarti per passare gli ingredienti avanti e indietro, gli chef di linea rimangono inattivi. L'autore ha dovuto ristrutturare il codice in modo che tutti gli ingredienti venissero spostati sulla GPU una sola volta all'inizio, invece di spostarli continuamente avanti e indietro.

La Soluzione: Ristrutturare la Cucina

Per far sì che il codice funzioni su GPU NVIDIA e AMD, l'autore ha dovuto eseguire una sorta di "chirurgia" sul codice TRIMEG:

• Appiattire la Mappa: Il codice utilizzava una mappa complessa per trovare dove si trovavano le particelle. Questa mappa era come un archivio disordinato. L'autore l'ha appiattita in una singola lista dritta, in modo che la GPU potesse leggerla istantaneamente senza perdersi.
• Risolvere la "Corsa": A volte, quando migliaia di chef di linea cercano di scrivere sulla stessa lavagna contemporaneamente, scrivono l'uno sopra l'altro (una "race condition"). L'autore ha individuato i punti in cui il codice faceva questo e lo ha corretto, in modo che ognuno scrivesse nella propria corsia.
• Il Compromesso "Uno per Tutti": Poiché i due marchi di GPU (NVIDIA e AMD) parlano lingue leggermente diverse, l'autore ha dovuto creare una singola versione del codice che funzioni per entrambi, anche se ciò significava utilizzare alcuni "accorgimenti" (come l'uso di un tipo specifico di allocazione della memoria che funzioni per entrambi, anche se non è l'assolutamente più veloce per uno dei due).

I Risultati: Ha Funzionato?

L'autore ha testato la nuova versione GPU rispetto alla vecchia versione CPU utilizzando due famosi "casi di test" (come gli standard di guida per una nuova auto):

1. Il Caso Ciclone: Una simulazione semplificata della turbolenza del plasma.
2. Il Caso TCV-X21: Una simulazione più complessa e realistica che coinvolge il bordo del plasma.

Il Verdetto:

• Velocità: La versione GPU è stata significativamente più veloce. In alcuni test, è stata quasi 30 volte più veloce della versione CPU eseguita su una singola macchina.
• Accuratezza: I risultati della GPU corrispondevano quasi perfettamente ai risultati della CPU. I "modelli meteorologici" (crescita dell'energia e strutture di turbolenza) apparivano identici.
• Portabilità: Il codice è riuscito a girare con successo sia sull'hardware NVIDIA che su quello AMD senza dover essere completamente riscritto per ciascuno.

Il Rovescio della Medaglia (Limitazioni)

L'autore è onesto riguardo alle limitazioni:

• Il "Traduttore" non è ancora perfetto: I compilatori (il software che trasforma il codice in linguaggio macchina) per queste GPU sono ancora in fase di maturazione. A volte producono risultati matematici leggermente diversi rispetto alla CPU, il che può causare piccoli errori nel tempo.
• Disallineamento dell'Hardware: Se avete un computer con molti core CPU ma una sola GPU, la GPU potrebbe trovarsi sopraffatta se cercate di darle troppi compiti contemporaneamente. L'autore ha scoperto che, per ottenere i migliori risultati, è necessario bilanciare quanti "chef" (processi MPI) avete rispetto a quanti "chef di linea" (thread GPU) sono disponibili.
• Nessuna "Soluzione Magica": Sebbene la parte di spostamento delle particelle abbia ricevuto una enorme spinta di velocità, altre parti della simulazione (come la risoluzione delle equazioni del campo magnetico) girano ancora sulla CPU perché gli strumenti per spostare quelle specifiche parti sulla GPU non sono ancora pronti.

Riassunto

In breve, questa tesi è una storia di ingegno ingegneristico. L'autore ha preso un codice di simulazione pesante, lento e complesso e ha insegnato con successo come eseguire il calcolo su moderne e potenti schede grafiche. Ha navigato in un campo minato di bug del software e limitazioni del compilatore per creare una versione che funzioni su due diversi tipi di hardware, dimostrando che possiamo simulare il plasma per la fusione molto più velocemente senza perdere accuratezza. È un passo cruciale verso il rendere la ricerca sull'energia da fusione più efficiente, anche se il viaggio verso una traduzione perfetta e completamente automatizzata non è ancora concluso.

Sommario tecnico

Sintesi Tecnica: Accelerazione GPU e Portabilità del Codice TRIMEG per Simulazioni Girocinetiche di Plasma tramite OpenMP

Definizione del Problema
Le simulazioni della fisica del plasma, in particolare i modelli girocinetici utilizzati per studiare instabilità e turbolenza nei dispositivi a fusione tokamak, sono computazionalmente intensive. Il codice TRIMEG, un risolutore particle-in-cell (PIC) ad alta precisione che utilizza un metodo agli elementi finiti C1 su mesh triangolari non strutturate, affronta sfide significative di tempo di esecuzione a causa dell'enorme numero di particelle (spesso da $10^7$ a $10^8$) richieste per simulazioni realistiche. Sebbene il codice impieghi già MPI per il parallelismo multi-nodo, le operazioni di "particle pushing" e di grid-to-particle (G2P) costituiscono il collo di bottiglia primario, consumando fino all'80% del tempo totale di esecuzione. La sfida consiste nell'accelerare questi specifici "hotspot" utilizzando le unità di elaborazione grafica (GPU) pur mantenendo la portabilità tra diverse architetture hardware (specificamente NVIDIA e AMD) e preservando la complessa struttura orientata agli oggetti del codice, che include polimorfismo e tipi derivati.

Metodologia
Lo studio si concentra sul porting del codice TRIMEG verso architetture GPU utilizzando l'API di offloading OpenMP (versione 4.0 e successive). La metodologia ha previsto:

1. Selezione del Target: Il kernel del particle pusher e le associate operazioni G2P (pullback, calcolo della densità e interpolazione della funzione di distribuzione) sono stati identificati come i target primari per l'offloading a causa della loro elevata intensità aritmetica e della mancanza di dipendenze inter-particella.
2. Ristrutturazione del Codice per la Portabilità: È stata necessaria una significativa ristrutturazione per superare le limitazioni dei compilatori sia in amdflang (AMD) che in nvfortran (NVIDIA). Le sfide chiave hanno incluso:
   • Polimorfismo: Entrambi i compilatori hanno incontrato difficoltà con i tipi derivati class() e le procedure legate ai tipi (type-bound procedures) all'interno delle regioni target OpenMP. La soluzione è consistita nel rifattorizzare il codice utilizzando dichiarazioni type() non polimorfiche dove possibile e nell'implementare un workaround per le dipendenze circolari tra le classi particella e campo utilizzando gerarchie di classi base/estese e direttive Fortran INCLUDE per duplicare i corpi delle funzioni.
   • Array Dinamici: Il codice utilizzava una libreria personalizzata che emula i vettori C per gli array dinamici. Poiché i kernel GPU non possono gestire facilmente l'allocazione dinamica o le complesse indirezioni di puntatori, la struttura di mappatura tra i bounding box e i triangoli della mesh è stata "appiattita" da un array di strutture a array 1D per facilitare i trasferimenti di memoria efficienti.
   • Gestione della Memoria: È stata implementata l'allocazione preventiva della memoria durante la fase di inizializzazione per minimizzare la latenza a runtime. Per le piattaforme AMD, è stato sfruttato lo Unified Shared Memory (USM) dove possibile, mentre per le piattaforme NVIDIA prive di supporto USM sono state utilizzate le direttive esplicite enter data, update ed exit data.
   • Consistenza Numerica: Per garantire che i risultati della GPU corrispondessero al riferimento CPU, le ottimizzazioni del compilatore che alterano l'aritmetica in virgola mobile (come le istruzioni Fused-Multiply-Add) sono state disabilitate (-ffp-contract=off per AMD, -Mnofma per NVIDIA). Le race condition nella libreria B-spline esterna sono state risolte passando da membri di oggetto condivisi ad array automatici dichiarati localmente.
3. Valutazione delle Prestazioni: L'implementazione è stata testata sui cluster Viper (AMD MI300A), Raven (NVIDIA A100) e Pitagora (NVIDIA H100). Le prestazioni sono state valutate attraverso:
   • Profiling dei Kernel: Utilizzo di rocprof-compute e nsys per analizzare l'occupazione delle risorse, la larghezza di banda della memoria e i mix di istruzioni.
   • Studi di Scalabilità: Sono stati condotti test di strong scaling per valutare l'efficienza dell'offloading ibrido MPI-OpenMP, esaminando specificamente l'impatto dell'oversubscription delle GPU con molteplici processi MPI.
   • Esplorazione della Dimensione della Griglia: Ottimizzazione del numero di team OpenMP e dei thread per team per massimizzare l'utilizzo dell'hardware.

Contributi Chiave

• Primo Porting Cross-Vendor: Questo lavoro presenta uno sforzo pionieristico nel porting di un complesso codice girocinetico in Fortran, orientato agli oggetti, sia su GPU NVIDIA che AMD utilizzando un singolo codebase tramite OpenMP offloading.
• Workaround per i Compilatori: La tesi documenta workaround specifici e non banali per le limitazioni dei compilatori riguardanti il polimorfismo, gli array dinamici e i pointer di procedura. Evidenzia la mancanza di una documentazione completa per nvfortran e amdflang in merito a queste funzionalità.
• Analisi del Parallelismo Ibrido: Lo studio fornisce un'analisi dettagliata dei compromessi nell'offloading ibrido MPI-OpenMP, dimostrando che sebbene l'accelerazione GPU sia efficace per il particle pusher, la mancanza di multithreading OpenMP nel codice originale necessita di oversubscription, il che può limitare la scalabilità su nodi con un alto numero di core ma risorse GPU limitate.
• Verifica Numerica: L'implementazione include un rigoroso processo di verifica confrontando i tassi di crescita dell'energia e le strutture modali 2D con i risultati della CPU, confermando che la versione GPU riproduce la fisica con alta fedeltà nonostante minori deviazioni numeriche causate dalla gestione della virgola mobile specifica del compilatore.

Risultati

• Speedup: Per un carico di lavoro realistico di $32 \times 10^6$ elettroni, l'implementazione GPU ha ottenuto uno speedup di circa 14.8x sul nodo AMD Viper e 29.6x sul nodo NVIDIA Pitagora rispetto alla versione CPU compilata con GCC sul cluster TOK.
• Efficienza del Kernel: Il kernel del particle pusher ha rappresentato la maggior parte del tempo di esecuzione. Il profiling su AMD MI300A ha mostrato un'elevata intensità aritmetica con tassi di hit L1/L2 superiori all'80%, sebbene solo il 18% degli accessi alla memoria fosse coalescente.
• Limitazioni di Scalabilità: I test di strong scaling hanno rivelato che, sebbene la parte accelerata via GPU scali bene, lo speedup complessivo dell'applicazione è limitato dalle parti non accelerate (es. field solvers utilizzando PETSc) e dall'overhead dell'oversubscription delle GPU. Sul cluster NVIDIA Pitagora, il supporto multi-GPU tramite OpenMP è risultato non funzionante nella versione del compilatore testata (nvfortran 24.9), limitando la capacità di utilizzare simultaneamente tutte le GPU disponibili su un nodo.
• Correttezza: Le simulazioni del caso Cyclone (modo ITG) e del caso TCV-X21 (instabilità ITG non lineare) hanno confermato che la versione GPU riproduce correttamente i tassi di crescita dell'energia e le strutture modali osservate nella versione CPU, con differenze attribuibili all'inizializzazione del generatore di numeri casuali e alle variazioni della virgola mobile specifiche del compilatore piuttosto che a errori algoritmici.

Significatività e Rivendicazioni
Il documento afferma che, sebbene l'OpenMP offloading offra una strada promettente per la portabilità tra diverse architetture HPC, non è una soluzione "senza soluzione di continuità" (seamless) per i codici legacy complessi. Il lavoro dimostra che ottenere una versione GPU funzionante e ad alte prestazioni richiede un'estesa esplorazione dei compilatori e una significativa ristrutturazione del codice per aggirare le attuali limitazioni nel supporto dei compilatori per le funzionalità avanzate di Fortran.

Gli autori sottolineano che il successo di questa portabilità dipende pesantemente dalla specifica versione del compilatore piuttosto che dal semplice paradigma di programmazione. Concludono che l'implementazione GPU di TRIMEG è uno strumento funzionale e accurato per simulazioni girocinetiche, capace di fornire sostanziali speedup per le parti computazionalmente più onerose del codice. Tuttavia, notano con modestia che il pieno potenziale dell'hardware (in particolare i nodi multi-GPU) è attualmente ostacolato da un supporto del compilatore immaturo per l'offloading multi-dispositivo e dalla mancanza di multithreading OpenMP nella struttura del codice CPU sottostante. Il lavoro funge da guida pratica e da "documentazione surrogata" per altri che tentano porting simili di codici Fortran complessi verso architetture eterogenee.