Benchmark Ansys Fluent su CRESCO NOTA TECNICA ENEA GRID/CRESCO: NTN201003 NOME FILE: NTN201003-BenchmarkFluentCresco-v1_0.doc DATA: 30/07/2010 STATO: Versione iniziale AUTORE: F. Ambrosino Abstract: Questa breve nota tecnica descrive le prestazioni in termini di performance di calcolo del codice di Ansys Fluent per un problema di fluidodinamica di un flusso turbolento attorno ad una geometria di Interesse industriale. Viene fatto un confronto tra 2 diverse architetture di calcolo presenti nel cluster Cresco[1] del centro di ricerche ENEA di Portici: Clovertown e Nehalem.
NOTA TECNICA NEPTUNIUS PROJECT 201003
Log Documento VERSIONE DATA COMMENTO AUTORE 1.0 30/07/2010 Versione iniziale F. Ambrosino
INDICE 1 - Descrizione...5 2 - Caso simulato...6 3 - Risultati...7 4 - Referenze...12
1 - Descrizione Fluent[2] è un software commerciale per la fluidodinamica computazionale (CFD) di largo utilizzo in molti settori dell'industria e del mondo accademico, basato sul metodo ai volumi finiti. Viene associato ai software collegati Gambit e TGrid per la generazione delle griglie di calcolo. ANSYS FLUENT software è in grado di modellare diverse fenomelogie fisiche necessarie per studiare flussi di diverso tipo, turbolenza, il trasferimento di calore e le reazioni per le applicazioni industriali che vanno dal flusso d'aria sopra un'ala di velivoli alla combustione in una fornace, dalla formazione di bolle al flusso di sangue ecc. Inoltre dispone di modelli speciali che danno al software la possibilità di modellare la combustione nel cilindro di un motore a combustione interna, aeroacustica, turbomacchine, sistemi multifase ecc. Fluent è disponibile in ENEA GRID con un certo numero di licenze di caso (cioè per simulare problemi diversi) e parallele (cioè per usare più core computazionali per la stessa simulazione).
2 - Caso simulato La simulazione utilizzata per il calcolo delle prestazioni è relativa al calcolo del campo fluidodinamico attorno ad una geometria di interesse industriale fornita da un partner del laboratorio virtuale NEPTUNIUS (Numerical codes for computational fluid dynamics and fluid structure interactions) nell ambito di una collaborazione con l unità UTICT: Ansaldo Ricerche. Non potendo entrare troppo nello specifico per via dell accordo di riservatezza stipulato dall autore con il CRIS (Centro Ricerche per il Sud e Ansaldo Energia) si può solo qui menzionare che il problema è relativo alla simulazione CFD di un flusso di gas in una camera di combustione. La geometria 3D modellata corrisponde ad una porzione della geometria completa infatti ricorrendo alla simmetria assiale si simula solo una parte della geometria considerando però opportune condizioni al contorno sulle sezioni radiali che vengono dette periodiche. La mesh computazionale è composta da 800000 celle tetraedriche. Il modello usato è incomprimibile, stazionario, basato sulla pressione e con solutore accoppiato; Non è presente alcun modello di cinetica chimica per la combustione. L equazione di conservazione dell energia non è attivata. Il modello comprende diverse specie gassose e diversi materiali per le componenti solide della camera. Il modello di turbolenza usato è Reynolds Averaged Navier Stokes (RANS) a 2 equazioni ed in particolare k-ε realizable. Fig. 2.1: Geometria del problema In figura 2.1 è mostrata una vista della geometria del problema usato come benchmark.
3 - Risultati Di seguito vengono illustrati le performance parallele delle simulazioni eseguite sul cluster CRESCO. Le simulazioni sono state fatte su due architetture diverse delle macchine presenti nel cluster e cioè con Intel Clovertown e Intel Nehalem. La simulazione usata come benchmark corrisponde a 20 iterazioni del caso illustrato precedentemente a partire da una soluzione iniziale. Le simulazioni sono state fatte con un core computazionale (simulazione seriale) e con numero di core crescenti in base 2 fino a 128 per i test su clovertown e fino a 96 core per i test su negale. Per le simulazioni parallele la decomposizione del dominio è stata ottimizzata specificando un criterio particolare per le simulazioni con numero di core maggiore uguale a 8 mentre è stato lasciato il criterio automatico di decomposizione per le simulazioni con 2 e 4 cores. Le archittetture hardware analizzate per i test sono: Clovertown: Blade IBM HS21 con Intel Dual Xeon Quad-Core E5345 (Clovertown), (2.33 GHz, 8 MB L2, 16 GB RAM). Nehalem: Blade IBM HS21 con Intel Dual Xeon Quad-Core Turbo Boost Nehalem E5530 (2.40 GHz, 8 MB L3, 16 GB RAM). I nodi sono tutti interconnessi con rete Infiniband IB 4X DDR. File system distribuito utilizzato: AFS. Le simulazioni eseguite su Clovertown sono state condotte con Ansys Fluent versione 6.3. Le simulazioni eseguite su Nehalem sono state condotte con Ansys Fluent versione 12.1. Definiamo qui alcuni termini e concetti per poter meglio leggere i risultati mostrati nei grafici seguenti: Ts = tempo (in secondi) per l esecuzione del benchmark in seriale (con un solo processore). Tn = tempo (in secondi) per l esecuzione del benchmark con n processori. Speed-up = Ts / Tn = quante volte il benchmark con n processori è stato più veloce di quello seriale sulla stessa architettura. Efficienza = Speed-up / n = indice sulla qualità dell uso dei core paralleli rispetto al benchmark seriale.
Rating = 86400 / Tn = Numero di benchmark con n processori che si possono eseguire in una giornata; rappresenta la velocità del benchmark in quanto maggiore è il rating più brevi sono le simulazioni. Fig. 3.1:Curve di Speed-up per i 2 benchmark In figura 3.1 è mostrato l andamento della curva dello speed-up per le 2 architetture analizzate. Per l architettura Clovertown il massimo dello speed-up si ottiene a 64 cores mentre per l architettura Nehalem è possibile che il massimo si ottenga per un numero di core anche maggiore ai 96 testati. Inoltre i valori dello speed-up sono più alti per Nehalem.
Fig. 3.2:Curve di Efficienza per i 2 benchmark In figura 3.2 è mostrato l andamento della curva dell efficienza per le 2 architetture analizzate. Per entrambe le architetture i valori scendo molto per numeri di cores grandi anche se l architettura Nehalem mostra un efficienza più alta rispetto alla Clovertown.
Fig. 3.3:Curve di Rating per i 2 benchmark Fig. 3.4:Rapporto tra i Rating per i 2 benchmark Nelle figure 3.3 e 3.4 è mostrato il rating per le 2 architetture ed il rapporto tra i valori delle stesse.
Come si può vedere chiaramente da queste ultime figure, anche se lo speed-up e l efficienza mostrano un leggero miglioramento per l architettura Nehalem, questa ha delle performance assolute (non in termini di scalabilità) molto migliori rispetto alla architettura Clovertown mostrando di esserne mediamente 3 volte più veloce per il particolare problema analizzato.
4 - Referenze [1] http://www.cresco.enea.it [2] http://www.fluent.com/