OBIETTIVO FLUENT
SEMINARIO PER L’UTILIZZO OTTIMALE
DI FLUENT NELL’AMBIENTE
DELLA GRIGLIA COMPUTAZIONALE
ENEA.IT
Dott. Roccetti Paolo
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);
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.
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.
HOW DO I SIMULATE A PREMIXED COMBUSTOR
Dr. G.Calchetti; Eng. M.Rufoloni
The following describes a series of FLUENTTM 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
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
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
VORTEX SHEDDING
Velocity Vectors released behind the Stator trailing edge
L’AMBIENTE E LE RISORSE ENEA
LA SOTTOMISSIONE CON ‘LSF’
L’interfaccia per l’utente:
……le funzionalità:
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
Gestione generale di una specifica richiesta al sistema
Cluster
Configuration
(STATICO)
Stato delle
Risorse
(TEMPO REALE)
Politica
delle code
(STATICO)
•Accoda la richiesta
Interfaccia
Grafica
(RICHIESTA)
LSF
•Assegna la risorsa
•Lancia il comando sul
calcolatore selezionato
Data Base Server
File Server
AFS
•Risolve la piattaforma
•Verifica i diritti di accesso
•Mantiene la coerenza dei dati
Client AFS
Cache
locale
L’ottimizzazione dell’interfaccia per
GAMBIT & FLUENT
Il telnet, i software e…..
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:
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:
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
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
LSF e lo stato delle piattaforme
Utilizzando l’interfaccia
troviamo l’opzione:
XLSMON
LSF e lo stato delle piattaforme
Utilizzando i comandi da una
qualsiasi piattaforma AFS
troviamo l’opzione:
LSLOAD “nomesede”
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:
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’;
Piattaforma
GAMBIT
FLUENT
Interactive
FLUENT
Batch
achille.casaccia.enea.it
OK
OK
OK
aiace.casaccia.enea.it
OK
OK
OK
diomede.casaccia.enea.it
OK
OK
OK
eca700.casaccia.enea.it
OK
OK
eth101/102/103/104
.sp.bologna.enea.it
OK
OK
OK
graphlabo.bologna.enea.it
OK
OK
OK
power3.bologna.enea.it
OK
OK
OK
TABELLA
OPERATIVA
PER
bw1/2/3/4/5/6/7/8/9/10
OK
? SI ma va in timeOK
out (inutilizzabile
.frascati.enea.it
GAMBIT & FLUENT
per ora)
eth101/105/109/110
OK
OK
OK
SULLE
PIATTAFORME
DISPONIBILI
.sp.frascati.enea.it
eth111/112/113/114
.sp.frascati.enea.it
OK
OK
OK
fenf.frascati.enea.it
OK
? OK ma va in
time-out
(inutilizzabile per
ora)
OK (ma verrà
disattivato per non
interagire con i nodi
bwi)
onyx2ced.frascati.enea.it
OK
OK
OK
sp3_1.frascati.enea.it
OK
OK
OK
infocal.trisaia.enea.it
OK ma ci sono
Problemi con i
Pulsanti-MAUSE
OK
OK
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).
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.
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
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
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.
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_1
45’ 20” / 2600”
22’ 30” / 2620”
11’30” / 2660”
6’ 20” / 2825 “
ONYX2ced
1h 14’
35’
20’
Bwi (LINUX)
39’ 10” / 1904.1
16’ 40” / 911 x
CPU”
10 ‘’00”/ ???
Il caso non
esce!
7’ 12” ????
Ma il caso non
esce!
SP11
(POWER 3
VECCHIO)
1h 17’ 40” /
4620”
1h 18’ 30” /
8837”
NO
NO
1h 56’
1h 3’ 38”
37’ 25”
26’ 15”
SP2/POWER2
(load-loveler)
NO
I rapporti di velocità
Nella tabella che segue vengono riportati i tempi di calcolo rapportati a
quelli ottenuti con l’SP3_1 :
Piattaforma
Con
1 CPU
Con
2 CPUs
Con
4 CPUs
Con
8 CPUs
SP3_1
45’ 20”
22’ 30”
11’30” / 2660”
6’ 20” / 2825 “
ONYX2ced
1.64
1.98
3.63
Bwi (LINUX)
0.86
0.74
0.87 ???
Ma il caso non
esce!
1.13 ???
Ma il caso non
esce
SP11
(POWER 3
VECCHIO)
1.73
3.47
NO
NO
2.55
2.83
3.35
4.33
SP2/POWER2
(load-loveler)
NO
I PRINCIPALI COMANDI DI LINEA ‘LSF’
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
GLI OBIETTIVI FUTURI
Sottomissioni di RUN GEOGRAFICI su piattaforme
omogenee
Sottomissioni di RUN GEOGRAFICI su piattaforme
non omogenee