OBIETTIVO FLUENT

1
OBIETTIVO FLUENT
SEMINARIO PER LUTILIZZO OTTIMALE DI FLUENT
NELLAMBIENTE DELLA GRIGLIA COMPUTAZIONALE
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

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 Tref950C, Tref1050C and Tref1150C.
Fig.2 shows the geometry setup.
 
 
4
Tref 1050C. The results of the simulations at
1050C are in qualitative agreement with those of
the case at 950C. 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 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 (AIRMETHANE) 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
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 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, FluentUtente)
• Interfacce specifiche sviluppate con lutenza
• 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
Lottimizzazione dellinterfaccia 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 loutput
• w done(Xidjob) fa iniziare il job
• quando finisce il job X
• u e-mail Yutente spedisce loutput
• allutente Y (si può usare invece di o)
• B begintime fa partire il job allorario
• 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 loutput
• w done(Xidjob) fa iniziare il job
• quando finisce il job X
• u e-mail Yutente spedisce loutput
• allutente Y (si può usare invece di o)
• b begintime fa partire il job allorario
• 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 lesecuzione 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
• 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
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
• gli utenti
• lo stato
• il tipo di coda
• lhost di sottomissione
• lhost su cui va eseguito il job
• listante di sottomissione
• il comando con cui il job è stato
• 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
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
bw1/2/3/4/5/6/7/8/9/10 .frascati.enea.it OK ? SI ma va in time-out (inutilizzabile per ora) OK
eth101/105/109/110 .sp.frascati.enea.it OK OK OK
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
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 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 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 gt 4 nel caso non
ci sia disponibilità, la scelta verrà effettuata
tra le piattaforme delle altre sedi aventi un
numero di CPUs libere gt 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 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.
Daltronde 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
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 1130 / 2660 6 20 / 2825
ONYX2ced 1h 14 35 20 NO
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
SP2/POWER2 (load-loveler) 1h 56 1h 3 38 37 25 26 15
27
I rapporti di velocità
Nella tabella che segue vengono riportati i
tempi di calcolo rapportati a quelli ottenuti con
lSP3_1
Piattaforma Con 1 CPU Con 2 CPUs Con 4 CPUs Con 8 CPUs
SP3_1 45 20 22 30 1130 / 2660 6 20 / 2825
ONYX2ced 1.64 1.98 3.63 NO
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
SP2/POWER2 (load-loveler) 2.55 2.83 3.35 4.33
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
31
(No Transcript)