La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

OBIETTIVO FLUENT SEMINARIO PER LUTILIZZO OTTIMALE DI FLUENT NELLAMBIENTE DI FLUENT NELLAMBIENTE DELLA GRIGLIA COMPUTAZIONALE DELLA GRIGLIA COMPUTAZIONALE.

Presentazioni simili


Presentazione sul tema: "OBIETTIVO FLUENT SEMINARIO PER LUTILIZZO OTTIMALE DI FLUENT NELLAMBIENTE DI FLUENT NELLAMBIENTE DELLA GRIGLIA COMPUTAZIONALE DELLA GRIGLIA COMPUTAZIONALE."— Transcript della presentazione:

1 OBIETTIVO FLUENT SEMINARIO PER LUTILIZZO OTTIMALE DI FLUENT NELLAMBIENTE DI FLUENT NELLAMBIENTE DELLA GRIGLIA COMPUTAZIONALE DELLA GRIGLIA COMPUTAZIONALE ENEA.IT ENEA.IT Dott. Roccetti Paolo

2 Fluent nasce con lesigenza di valutare il campo termo-fluidodinamico associato a flussi in geometrie complesse. Allinterno 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 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 FLUENT TM 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. HOW DO I SIMULATE A MILD COMBUSTOR BURNER Dr. G.Calchetti – Eng. M.Rufoloni

4 T ref = 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 of FLUENT TM simulations of the thermofluidynamic behavior of a KTI TM burner (Kinetics Thecnology International) Model KT (fig.1,2) and qualitative comparisons with some experimental data. The objective is the evaluation of the predictive behavior of the FLUENT TM (V.5.3) implementation of the Zimont premixed combustion model. Combustion Chamber Burner Head 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.

6 Picture of the combustion chamber inlet zone. Temperature contours 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.

7 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. Applicazione di modelli avanzati di turbolenza LES allo studio numerico di uno stadio di turbina assiale a gas Dott. Roccetti Paolo Stator blade temperature contours Near stator hub path lines

8 VORTEX SHEDDING Velocity Vectors released behind the Stator trailing edge

9 LAMBIENTE E LE RISORSE ENEA

10 LA SOTTOMISSIONE CON LSF Linterfaccia per lutente: ……le funzionalità:

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

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

13 Lottimizzazione dellinterfaccia per GAMBIT & FLUENT Il telnet, i software e…..

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

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

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

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 lesecuzione che permettono di eseguire tutti i passi necessari per la preparazione e lesecuzione della simulazione. 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 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 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 precedenti. Successivamente si può sottomettere la simulazione utilizzando un semplice file per il BATCH che contenga solamente istruzioni di lettura, iterazione e scrittura, come per il BATCH che contenga solamente istruzioni di lettura, iterazione e scrittura, come nellesempio che segue (valido per una simulazione stazionaria): nellesempio 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 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 linterfaccia troviamo lopzione: XLSMON

19 LSF e lo stato delle piattaforme Utilizzando i comandi da una qualsiasi piattaforma AFS troviamo lopzione: LSLOAD nomesede

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

21 Diverse funzioni sono disponibili con lLSF-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 PiattaformaGAMBIT FLUENT Interactive FLUENT Batch Batchachille.casaccia.enea.itOKOKOK aiace.casaccia.enea.itOKOKOK diomede.casaccia.enea.itOKOKOK eca700.casaccia.enea.itOKOK eth101/102/103/104.sp.bologna.enea.itOKOKOK graphlabo.bologna.enea.itOKOKOK power3.bologna.enea.itOKOKOK bw1/2/3/4/5/6/7/8/9/10.frascati.enea.itOK ? SI ma va in time- out (inutilizzabile per ora) OK eth101/105/109/110.sp.frascati.enea.itOKOKOK eth111/112/113/114.sp.frascati.enea.itOKOKOK fenf.frascati.enea.itOK ? OK ma va in time-out (inutilizzabile per ora) OK (ma verrà disattivato per non interagire con i nodi bwi) onyx2ced.frascati.enea.itOKOKOK sp3_1.frascati.enea.itOKOKOK infocal.trisaia.enea.it OK ma ci sono Problemi con i Pulsanti-MAUSEOKOK TABELLA OPERATIVA PER GAMBIT & FLUENT SULLE PIATTAFORME DISPONIBILI 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 lhost desiderato, oppure selezionando esclusivamente lhost-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 (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. a quelle nelle altre sedi. Le verifiche sono state effettuate dal cluster di Frascati in uscita verso le altre sedi (Casaccia, Bologna, Trisaia). (Casaccia, Bologna, Trisaia).

24 Esempio 1: se si sottomette dallinterfaccia di Frascati un caso parallelo con 4 processori, senza se si sottomette dallinterfaccia 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 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 dallinterfaccia 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 è costituito da una simulazione standard, ovvero da un flusso stazionario e turbolento in una geometria confinata. Fondamentale è il numero di volumi finiti in e turbolento in una geometria confinata. Fondamentale è il numero di volumi finiti in cui viene suddiviso il dominio. Infatti esso risulta proporzionale alla RAM necessaria cui viene suddiviso il dominio. Infatti esso risulta proporzionale alla RAM necessaria per la simulazione ed inversamente proporzionale alle velocità di calcolo. 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; parallelo, visto che la comunicazione tra i nodi rallenta la velocità di calcolo; dunque la simulazione in parallelo è efficace solamente se il guadagno ottenuto dunque la simulazione in parallelo è efficace solamente se il guadagno ottenuto con la partizione della griglia risulta maggiore delle perdite per con la partizione della griglia risulta maggiore delle perdite per la comunicazione tra i nodi. Daltronde un numero troppo elevato di celle di calcolo la comunicazione tra i nodi. Daltronde un numero troppo elevato di celle di calcolo avrebbe richiesto un tempo eccessivo per ogni singolo test. avrebbe richiesto un tempo eccessivo per ogni singolo test. - Un compromesso accettabile è stato raggiunto utilizzando una mesh costituita - Un compromesso accettabile è stato raggiunto utilizzando una mesh costituita da circa elementi. da circa elementi.

26 Le prove dinamiche per il caso test Piattaforma Tempo di calcolo e CPU time con 1 CPU Tempo di calcolo e CPU time con 2 CPUs Tempo di calcolo e CPU time con 4 CPUs Tempo di calcolo e CPU time con 8 CPUs SP3_ / / / / / 2825 ONYX2ced ONYX2ced 1h NO Bwi (LINUX) Bwi (LINUX) / / 911 x CPU 10 00/ ??? Il caso non esce! 7 12 ???? Ma il caso non esce! SP11 (POWER 3 VECCHIO) 1h / h / 8837 NONO SP2/POWER2 (load-loveler) SP2/POWER2 (load-loveler) 1h 56 1h

27 PiattaformaCon 1 CPU Con 2 CPUs Con 4 CPUs Con 8 CPUs SP3_ / / / 2825 ONYX2ced ONYX2ced NO Bwi (LINUX) Bwi (LINUX) ??? Ma il caso non esce! 1.13 ??? Ma il caso non esce SP11 (POWER 3 VECCHIO) NONO SP2/POWER2 (load-loveler) SP2/POWER2 (load-loveler) I rapporti di velocità Nella tabella che segue vengono riportati i tempi di calcolo rapportati a quelli ottenuti con lSP3_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:

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

31


Scaricare ppt "OBIETTIVO FLUENT SEMINARIO PER LUTILIZZO OTTIMALE DI FLUENT NELLAMBIENTE DI FLUENT NELLAMBIENTE DELLA GRIGLIA COMPUTAZIONALE DELLA GRIGLIA COMPUTAZIONALE."

Presentazioni simili


Annunci Google