The Pulse
Convergent Science completa una simulazione CFD da circa 536 milioni di celle in 3,62 ore su GPU B200
Convergent Science ha completato una simulazione di fluidodinamica computazionale da circa 536 milioni di celle in 3,62 ore su due istanze NVIDIA HGX B200. Lo studio congiunto ha anche misurato la scalabilità del software CONVERGE CFD sui s
AI.info Team · Scritto con l’IA · verificato ·
Convergent Science ha completato una simulazione di fluidodinamica computazionale (CFD) da circa 536 milioni di celle in 3,62 ore su due istanze NVIDIA HGX B200, usando 16 GPU NVIDIA Blackwell. L’esecuzione ha verificato fino a che punto la configurazione potesse gestire un caso ed era separata dalla matrice di scalabilità dello studio. Convergent Science e CoreWeave hanno usato il software CONVERGE CFD per il progetto, che ha anche misurato l’accuratezza del solutore su GPU rispetto a un caso di test consolidato e ha esaminato la scalabilità su due configurazioni hardware.
Perché il test ha usato la simulazione numerica diretta
Il team ha scelto la simulazione numerica diretta (DNS), che calcola il flusso turbolento a tutte le sue scale senza un modello di turbolenza. CoreWeave descrive la DNS come l’approccio di simulazione a più alta fedeltà e un riferimento per calibrare i modelli di turbolenza usati in produzione. Risolvere i vortici più piccoli richiede celle molto piccole e passi temporali brevi, rendendo la DNS impegnativa dal punto di vista computazionale.
Molte simulazioni industriali usano invece i metodi di Navier-Stokes mediati secondo Reynolds (RANS). Questi usano un modello di turbolenza per calcolare i movimenti su larga scala e stimare quelli più piccoli, riducendo il carico computazionale. CoreWeave osserva che la DNS impiega meno equazioni rispetto ai modelli RANS usati quotidianamente nell’industria. Un caso di produzione con lo stesso numero di celle può quindi richiedere più memoria, soprattutto se include fenomeni fisici aggiuntivi come le reazioni di combustione.
Due sistemi GPU, due tipi di scalabilità
La matrice di scalabilità ha usato un caso tridimensionale validato di flusso turbolento che perde energia nel tempo. Nella scalabilità debole, il caso cresce con l’aumentare delle risorse GPU; nella scalabilità forte, il caso rimane invariato mentre aumenta il numero di GPU che vi lavorano. CoreWeave parte dalla scalabilità debole perché i team di ingegneria hanno spesso bisogno di eseguire casi più grandi e dettagliati. La scalabilità forte verifica quanto prima può essere completato un caso esistente.
Sui sistemi NVIDIA RTX PRO 6000 Blackwell Server, le esecuzioni per la scalabilità debole sono passate da circa 16,8 milioni di celle su due GPU a circa 67,1 milioni su otto. I test di scalabilità forte hanno mantenuto il caso a circa 67,1 milioni di celle e hanno usato due, quattro o otto GPU. Su NVIDIA HGX B200, le esecuzioni per la scalabilità debole sono andate da circa 33,6 milioni di celle su una GPU a circa 134,2 milioni su quattro. La scalabilità forte è stata testata su circa 268,4 milioni di celle con otto, 12 e 16 GPU.
I due sistemi differiscono per capacità di memoria e connessioni tra GPU. La configurazione RTX PRO ha 96 GB di memoria per GPU e connessioni PCIe Gen5. La configurazione HGX B200 ha 180 GB per GPU e NVLink di quinta generazione all’interno di un nodo. Per la comunicazione tra nodi, il test ha usato una rete NVIDIA Quantum-2 InfiniBand da 400 Gb/s. CoreWeave afferma che la comunicazione tra GPU può influire sulla scalabilità, perché le GPU si scambiano i dati ai confini a ogni passo temporale.
La memoria fissa il limite prima della velocità
Il solo numero di celle non determina la quantità di memoria necessaria a una simulazione. I requisiti dipendono anche dai fenomeni fisici modellati, dalla precisione dei valori memorizzati, dai dati di lavoro del solutore e dal fatto che la griglia cambi o meno durante l’esecuzione. Il caso testato ha usato una DNS monofase senza reazioni. CoreWeave afferma che il raffinamento adattivo della griglia può concentrare le celle dove servono e rimuoverle altrove, per cui il numero di celle varia durante un’esecuzione e la capacità dovrebbe tenere conto del picco.
L’esecuzione da 536 milioni di celle stabilisce il caso più grande gestito da questa configurazione e da questo hardware. Le esecuzioni di scalabilità separate misurano le prestazioni al variare del numero di GPU o delle dimensioni del caso. CoreWeave afferma che lo studio completo include la validazione rispetto a dati DNS pubblicati, la scalabilità debole e forte su entrambe le configurazioni GPU e l’analisi dei limiti di efficienza di un solutore a doppia precisione. I job sono stati eseguiti su nodi bare-metal tramite SUNK, l’implementazione di Slurm su Kubernetes di CoreWeave.
«Questo è stato uno dei migliori cluster su cui abbiamo testato CONVERGE.»
Cooper Burns, responsabile del team HPC di Convergent Science