OBIETTIVO FLUENT

1. OBIETTIVO FLUENT SEMINARIO PER L’UTILIZZO OTTIMALE DI FLUENT NELL’AMBIENTE DELLA GRIGLIA COMPUTAZIONALE ENEA.IT Dott. Roccetti Paolo

2. Fluent nasce con l’esigenza di valutare il campo • termo-fluidodinamico associato a flussi • in geometrie complesse. • All’interno del codice sono implementati diversi modelli che permettono • di affrontare problematiche inerenti: • - flussi stazionari e transitori; • il trasferimento di calore per convezione e/o irraggiamento; • flussi periodici; • flussi in rotazione e con componenti elicoidali; • flussi compressibili ed incompressibili; • flussi non viscosi; • flussi laminari e turbolenti; • il trasporto delle specie chimiche e flussi reattivi; • modelli per la formazione di inquinanti; • modelli per il cambiamento di fase; • flussi multifase; • flussi in regioni in movimento relativo; • flussi in geometrie variabili (griglie dinamiche);

3. HOW DO I SIMULATE A MILD COMBUSTOR BURNER Dr. G.Calchetti – Eng. M.Rufoloni INTRODUCTION The following synthetizes the characterization of the burner “WS Rekumat C-150 B”, based on flameless combustion technology. This burner (40 kW), installed in the ENEA experimental facility M.C.D. (Mild Combustion Demonstrator, fig.1 is designed in order to operate either in conventional flame or in diluted combustion. Some 3-D reactive Navier-Stokes simulations, by means of the the FLUENTTM code, have been performed. Experimental data were also collected and comparisons have been done between numerical simulations and experiments. Two different modelling approaches have been applied in the simulations. One based on the P.D.F. (Probability Density Functions) approach – equilibrium assumption and the other one based on eddy-dissipation (EDC) – one step finite kinetics approach. We simulated three working conditions for the burner: the most important parameter is Tref that is a reference temperature in the burner, a sort of mean temperature. So we performed three simulations, with Tref=950°C, Tref=1050°C and Tref=1150°C. Fig.2 shows the geometry setup.

4. Tref = 1050°C. The results of the simulations at 1050°C are in qualitative agreement with those of the case at 950°C. In this physical situation, the higher process temperature reduces the ignition delay. From the examination of the results, shown in fig.6,7,8 it can be seen that still in this case the M.&H. – 1 step model gives a better prediction of the temperature field.

5. HOW DO I SIMULATE A PREMIXED COMBUSTOR Dr. G.Calchetti; Eng. M.Rufoloni The following describes a series ofFLUENTTM simulations of the thermofluidynamic behavior of a KTITM burner (Kinetics Thecnology International) Model KT 80-80 (fig.1,2) and qualitative comparisons with some experimental data. The objective is the evaluation of the predictive behavior of the FLUENTTM (V.5.3) implementation of the Zimont premixed combustion model. We first performed a cold (non-reactive) simulation, in order to calculate the mixing of the reacting species (AIR+METHANE) on the whole Geometry (Burner + combustion chamber), using a compressible model. This because the FLUENT Zimont model works only for perfectly premixed mixtures. In fig.3 is shown the CH4 mass fraction contours. At the combustion chamber inlet we have a perfectly premixed mixture. Combustion Chamber Burner Head

6. Picture of the combustion chamber inlet zone. CH4 mass fraction contours CONCLUSIONS The present work represents the first application of the FLUENT implementation of the Zimont premixed combustion model in ENEA. The results obtained by such model was encouraging: we found a good qualitative description of the combustion zone. Temperature contours

7. Applicazione di modelli avanzati di turbolenza LES allo studio numerico di uno stadio di turbina assiale a gas Dott. Roccetti Paolo La simulazione riguarda il primo stadio di una turbina assiale di alta pressione, utilizzata in “high bypass ratio engine”, realizzata nel Lewis Reserch Center della NASA. Near stator hub path lines Stator blade temperature contours

8. VORTEX SHEDDING Velocity Vectors released behind the Stator trailing edge

9. L’AMBIENTE E LE RISORSE ENEA

10. LA SOTTOMISSIONE CON ‘LSF’ L’interfaccia per l’utente: ……le funzionalità:

11. Principali funzionalità di LSF: • Richiesta di una risorsa di calcolo • Per piattaforma/modello • Specifica (Modalità che sarà ridotta al minimo) • Richiesta di un software commerciale specifico • Completamente automatico • Per casi speciali è previsto specificare il calcolatore • Sottomissione di programmi utente • Specificare modello/piattaforma e coda • Sottomissione di codici (Abaqus, Fluent…’Utente’) • Interfacce specifiche sviluppate con l’utenza • Funzioni di monitoring sia del sistema che dei job, Help, Edit

12. Gestione generale di una specifica richiesta al sistema Politica delle code (STATICO) Cluster Configuration (STATICO) Stato delle Risorse (TEMPO REALE) • Accoda la richiesta • Assegna la risorsa • Lancia il comando sul calcolatore selezionato Interfaccia Grafica (RICHIESTA) LSF Data Base Server AFS • Risolve la piattaforma • Verifica i diritti di accesso • Mantiene la coerenza dei dati File Server Client AFS Cache locale

13. L’ottimizzazione dell’interfaccia per GAMBIT & FLUENT Il telnet, i software e…..

14. Per il GAMBIT appare una semplice schermata in cui è possibile selezionare due tipi di opzioni: • LSF Options: • -o nomefile.%J file per l’output; • w “done(Xidjob)”: fa iniziare il job • quando finisce il job X; • u e-mail Yutente: spedisce l’output • all’utente Y (si può usare invece di –o); • B begintime: fa partire il job all’orario • prescelto compatibilmente con i nodi e • le licenze disponibili; • E command: esegue un comando prima di • sottomettere il job; - Options:

15. Per FLUENT la schermata è leggermente più complessa; anche qui ritroviamo le opzioni come in precedenza: • LSF Options: • -o nomefile.%J file per l’output; • w “done(Xidjob)”: fa iniziare il job • quando finisce il job X; • u e-mail Yutente: spedisce l’output • all’utente Y (si può usare invece di –o); • b begintime: fa partire il job all’orario • prescelto compatibilmente con i nodi e • le licenze disponibili; • E command: esegue un comando prima di • sottomettere il job; - Options:

16. FLUENT version: 2d, 2ddp, 3d, 3ddp Il numero di processori La coda LSF per il BATCH: Small_10m,; Medium_2h; Large Il file di input per il BATCH Il tipo di piattaforma (solo per il parallelo)

17. Il file di input per il FLUENT in modalità BATCH - Per FLUENT esistono una serie di comandi manuali (consultabili nell’ HELP) che permettono di eseguire tutti i passi necessari per la preparazione e l’esecuzione della simulazione . • Il sistema più semplice ed efficace per preparare il file di INPUT per la modalità • BATCH è quello di preparare la simulazione in interattivo (settando modelli, condizioni • al contorno e parametri) e di scrivere un “nomefile”.cas che contenga tutte le informazioni • precedenti. Successivamente si può sottomettere la simulazione utilizzando un semplice file • per il BATCH che contenga solamente istruzioni di lettura, iterazione e scrittura, come • nell’esempio che segue (valido per una simulazione stazionaria): readcase “nomefile-lettura”.cas solve init/init (oppure readdata “nomefile-lettura”.dat ) iterate “numero delle iterazioni” writedata “nomefile-scrittura”.dat exit yes

18. LSF e lo stato delle piattaforme Utilizzando l’interfaccia troviamo l’opzione: XLSMON

19. LSF e lo stato delle piattaforme Utilizzando i comandi da una qualsiasi piattaforma AFS troviamo l’opzione: LSLOAD “nomesede”

20. LSF-BATCH e lo stato del job sottomesso • Cliccando su LSF-BATCH appare una • schermata in cui compaiono: • i ‘job-identifier; • gli utenti; • lo stato; • il tipo di coda; • l’host di sottomissione; • l’host su cui va eseguito il job; • l’istante di sottomissione; • il comando con cui il job è stato lanciato. Lo stato del job può risultare:

21. Diverse funzioni sono disponibili con l’LSF-BATCH: • tra le più importanti ricordiamo: • la modifica del job; • la sospensione del job; • la terminazione del job; • il monitoraggio dei dettagli • il monitoraggio della storia del job; • il monitoraggio dello ‘standard output’;

22. TABELLA OPERATIVA PER GAMBIT & FLUENT SULLE PIATTAFORME DISPONIBILI

23. La sottomissione semplice e quella multicluster Nel caso in cui si sottometta una simulazione senza specificare l’”host” desiderato, oppure selezionando esclusivamente l’”host-type”, il sistema provvederà alla scelta (secondo parametri prestabiliti) della piattaforma considerata più scarica al momento, compatibilmente con le caratteristiche richieste per la simulazione (numero di CPUs, RAM necessaria, ecc..). La scelta verrà effettuata in primis tra le piattaforme disponibili nella sede di sottomissione, passando successivamente a quelle nelle altre sedi. Le verifiche sono state effettuate dal cluster di Frascati in uscita verso le altre sedi (Casaccia, Bologna, Trisaia).

24. Esempio 1: se si sottomette dall’interfaccia di Frascati un caso parallelo con 4 processori, senza specificare la piattaforma, il sistema proverà a sottomettere la simulazione scegliendo la più “scarica” tra le piattaforme di Frascati con un numero di CPUs libere >= 4 : nel caso non ci sia disponibilità, la scelta verrà effettuata tra le piattaforme delle altre sedi aventi un numero di CPUs libere >= 4. Esempio 2: se si sottomette dall’interfaccia di Frascati un caso parallelo con 2 processori specificando l’ “host-type” (ad esempio SGI), il sistema proverà la sottomissione sulla piattaforma ONYX2CED di Frascati; nel caso questa non avesse le 2 CPUs disponibili, verrà effettuato un tentativo di sottomissione sulle piattaforme SGI delle altre sedi, ovvero su ACHILLE o AIACE per la sede della CASACCIA e sulla GRAPHLABO per la sede di BOLOGNA.

25. IL caso TEST - Il caso utilizzato per testare le capacità del sistema nel gestire la sottomissione è costituito da una simulazione standard, ovvero da un flusso stazionario eturbolento in una geometria confinata. Fondamentale è il numero di volumi finiti in cui viene suddiviso il dominio. Infatti esso risulta proporzionale alla RAM necessaria per la simulazione ed inversamente proporzionale alle velocità di calcolo. - Il numero deve essere sufficientemente elevato per rendere efficaci le simulazioni in parallelo, visto che la comunicazione tra i nodi rallenta la velocità di calcolo; dunque la simulazione in parallelo è efficace solamente se il guadagno ottenuto con la partizione della griglia risulta maggiore delle perdite per la comunicazione tra i nodi. D’altronde un numero troppo elevato di celle di calcolo avrebbe richiesto un tempo eccessivo per ogni singolo test. - Un compromesso accettabile è stato raggiunto utilizzando una mesh costituita da circa 310000 elementi.

26. Le prove dinamiche per il caso test

27. I rapporti di velocità Nella tabella che segue vengono riportati i tempi di calcolo rapportati a quelli ottenuti con l’SP3_1 :

28. I PRINCIPALI COMANDI DI LINEA ‘LSF’

29. COME ACCEDERE AL SISTEMA TRAMITE ‘CITRIX’ Le istruzioni per scaricare ed installare il client ICA di Citrix collegarsi con il sito: www.bologna.enea.it/citrix/index.html

30. GLI OBIETTIVI FUTURI Sottomissioni di RUN GEOGRAFICI su piattaforme omogenee Sottomissioni di RUN GEOGRAFICI su piattaforme non omogenee