Studio del comfort termico e del consumo energetico in uno stadio di calcio climatizzato progettato per un clima caldo e umido

14 
 
3.4 Impostazione delle simulazioni 
Lo scopo di questo lavoro è valutare le condizioni di comfort o discomfort termico per gli spettatori 
e per gli atleti che occupano virtualmente lo stadio modello collocato a Doha, andando a variare di 
simulazione in simulazione i parametri di temperatura, portata ed umidità dell’impianto di 
condizionamento.  
Il clima considerato è quello caldo-umido tipico qatariota dei mesi di novembre e dicembre, periodo 
in cui è previsto lo svolgimento dei mondiali di calcio del 2022. Le temperature a cavallo tra 
novembre e dicembre possono raggiungere i 30°C, associati ad una umidità relativa anche del 70%. 
Sono quindi questi due parametri i valori climatici esterni considerati in ogni simulazione.  
3.4.1 Costruzione della mesh 
Perché il volume di aria di paragrafo 2.3 sia utilizzabile per simulazioni di tipo CFD è necessario che 
esso sia discretizzato, dunque è necessaria la creazione di una griglia di calcolo o mesh. 
Per procedere si è deciso di utilizzare Salome, una piattaforma CAE che integra soluzioni open source 
per la simulazione, il meshing, il calcolo numerico, la visualizzazione ed analisi dei risultati. Salome è 
scaricabile gratuitamente dal sito ufficiale [8].  
In particolare di Salome è stata utilizzata la sezione apposita per la progettazione delle mesh.  
Per quanto riguarda le mesh si può dire che ne esistono principalmente di due tipi: strutturate e non 
strutturate [9].  
Una griglia si definisce strutturata quando la numerazione dei nodi appartenenti a ciascun elemento 
di essa può essere ottenuta attraverso semplici operazioni matematiche. Un esempio può essere una 
mesh tridimensionale costituita interamente da esaedri. Una mesh strutturata ben progettata 
garantisce risultati numerici accurati; inoltre la numerazione ordinata degli elementi garantisce 
efficienza e velocità degli algoritmi di risoluzione. Le mesh strutturate consentono il controllo sulle 
dimensioni delle celle, tuttavia risulta difficile generare griglie su geometrie con un certo grado di 
complessità e altrettanto difficile imporre degli infittimenti nelle zone di maggior interesse del 
dominio. 
Per rimediare a questa poca adattività di griglia si ricorre talvolta a griglie strutturate a blocchi, o 
multiblocco, ottenute partizionando a priori il dominio in sottodomini di geometria più semplice e 
quindi creando una mesh per ciascun di essi. Risulta però complesso interconnettere i sottodomini 
e gestirli in modo efficiente. La suddivisione è poco automatizzabile.
15 
 
Per ovviare a queste complicazioni può essere conveniente ricorrere a griglie non strutturate, per 
esempio una griglia tridimensionale ad elementi tetraedrici oppure mista a tetraedri e prismi.  
Il vantaggio è una maggiore flessibilità geometrica che consente con facilità addensamenti nelle zone 
in cui sono richiesti ed una elevata automazione del processo di generazione. La mesh non 
strutturata, rispetto a quella strutturata, data la conformazione irregolare delle celle e la 
numerazione disordinata è contraddistinta da una accuratezza minore della soluzione che può 
talvolta comportare problemi di convergenza, nonché una minore efficienza tempistica degli 
algoritmi di risoluzione. Anche il controllo sulle dimensioni di cella risulta meno raffinato. 
 
 
Figura 8: Esempio di mesh strutturata bidimensionale. 
 
Figura 9: Esempio di mesh non strutturata 
bidimensionale. 
Il volume di aria interno allo stadio è una geometria complessa e irregolare, con numerosi spigoli e 
curve. Pertanto non è stato possibile riuscire nella creazione di una mesh strutturata costituita da 
soli esaedri. 
Si è optato invece per la creazione di una mesh non strutturata, costituita da soli tetraedri (Fig. 10 e 
Fig. 11), meno problematica nella realizzazione ma a costo di una minore rapidità di calcolo in 
OpenFOAM. Tale mesh è stata realizzata automaticamente tramite l’algoritmo NETGEN 1D-2D-3D, 
implementato di default nel software Salome. Si è posta attenzione al diverso infittimento della mesh 
da zona a zona del dominio, imponendo all’algoritmo il rispetto di alcune condizioni di infittimento 
impostate manualmente nelle zone volute.  
Quindi la mesh finale risulta più fitta nelle zone di maggiore interesse del volume di aria ai fini di 
questo studio, quali le zone delle gradinate in cui siedono gli spettatori e quelle al livello del campo 
occupate dagli atleti e dai loro staff (Fig. 11).
16 
 
 
Figura 10: Mesh non strutturata del volume d'aria realizzata 
con Salome. 
 
Figura 11: Ingrandimento su un singolo settore della 
mesh. 
La mesh generata risulta costituita da: 
• 409482 nodi; 
• 75516 spigoli; 
• 207810 facce; 
• 2129555 elementi, esclusivamente di forma tetraedrica. 
La mesh dopo la generazione richiede un ultimo accorgimento prima di essere pronta per 
l’esportazione e per l’utilizzo in OpenFOAM. Esso consiste nella creazione di gruppi, ovvero nella 
definizione dei raggruppamenti di facce esterne sulle quali poi possono essere fissate le condizioni 
al contorno in OpenFOAM. 
I gruppi creati sono così nominati e definiti (Fig. 12 e Fig. 13): 
• Sky: l’unica faccia del volume di aria direttamente a contatto con l’aria esterna; corrisponde 
all’apertura nel centro della copertura; 
• Campo: chiusura inferiore del volume di aria; 
• BocchetteSup: rappresentano le facce verticali delle gradinate dove avviene l’immissione 
dell’aria condizionata nell’anello superiore dello stadio; 
• BocchetteMed: rappresentano le facce verticali delle gradinate dove avviene l’immissione 
dell’aria condizionata nell’anello medio dello stadio; 
• BocchetteInf: rappresentano le facce verticali delle gradinate dove avviene l’immissione 
dell’aria condizionata nell’anello inferiore dello stadio;
17 
 
• BocchetteCampo: rappresentano le facce verticali dove avviene l’immissione dell’aria 
condizionata a servizio del campo; 
• SeduteSup: corrispondono alle facce orizzontali laddove siedono gli spettatori dell’anello 
superiore; 
• SeduteMed: corrispondono alle facce orizzontali laddove siedono gli spettatori dell’anello 
medio; 
• SeduteInf: corrispondono alle facce orizzontali laddove siedono gli spettatori dell’anello 
inferiore; 
• Roof: corrisponde alle facce rimaste del volume d’aria, non rientranti nei gruppi precedenti. 
Nella definizione dei gruppi sono state introdotte due semplificazioni importanti. La prima è presente 
in tutti i gruppi di Bocchette, dove l’immissione dell’aria viene considerata spalmata su tutta la 
superficie verticale delle gradinate, mentre realmente essa è localizzata nelle singole bocchette, che 
rappresentano una percentuale di questa superficie. La seconda è nei gruppi di Sedute che 
rappresentano interamente la superficie orizzontale delle gradinate, non la sola area occupata 
effettivamente dai seggiolini. L’utilità di queste semplificazioni sarà più chiara nel paragrafo 3.4.3.  
 
 
Figura 12: Gruppi di facce creati con Salome.
18 
 
 
Figura 13: Ingrandimento dei gruppi di facce creati con Salome. 
Una volta creati i gruppi si può procedere in Salome con l’esportazione della mesh in formato UNV. 
Questo formato viene riconosciuto in OpenFOAM e convertito in file di testo contenenti le 
informazioni sulla mesh tramite l’utility ideasUnvToFoam.  
Risulta molto utile una seconda utility di OpenFOAM, checkMesh, la quale fornisce le informazioni di 
base sulla qualità della mesh importata. Tre parametri di qualità risultano particolarmente 
importanti per non incorrere in problemi ed errori durante la simulazione: 
• non-ortogonalità: si misura in gradi e si manifesta nella rappresentazione di superfici curve 
usando poche celle; è valutata come l’angolo del vettore che unisci due centroidi di cella ed 
il vettore ortogonale alla faccia in comune. In OpenFOAM risultano problematiche celle con 
non-ortogonalità superiore a 70 gradi; 
• skewness: rappresenta lo scostamento che unisce due centroidi dal centro della faccia. 
Fornisce una misura della deviazione di una cella in esame rispetto ad una “cella ideale”; 
• aspect ratio: è definito come il rapporto tra la dimensione più grande e quella più piccola 
della cella e non deve essere troppo elevato.  
L’utility checkMesh (Fig. 14) ha restituito un risultato positivo non segnalando alcun tipo di elevata 
criticità (Mesh OK. End). Si può concludere che la mesh costruita risulta di qualità sufficiente per 
l’utilizzo nelle simulazioni.
19 
 
 
Figura 14: Schermata checkMesh. 
3.4.2 Scelta dei solver 
Ciascuna simulazione è stata svolta in due fasi per garantirne la stabilità, con due solver differenti 
basati sulle equazioni di Navier-Stokes: 
1. simpleFoam: steady-state solver per flussi incomprimibili; 
2. moistBuoyantBoussinesqSimpleFoam: steady-state solver per flussi turbolenti di fluidi 
incomprimibili.  
Il modello di turbolenza in entrambe le fasi è di tipo RANS, in particolare si è scelto il modello k-
omega Shear Stress Transport (SST) presente tra i modelli implementati di default in OpenFOAM.  
Ogni simulazione è proceduta nella prima fase con il simpleFoam, il quale richiede in ingresso la 
velocità (U), la pressione atmosferica (p), l’energia cinetica turbolenta (k), il coefficiente di 
dissipazione turbolenta (omega) e la viscosità cinematica turbolenta (nut). Quando il simpleFoam è 
arrivato a convergenza, con residui ormai trascurabili, inizia la seconda fase con il 
moistBuoyantBoussinesqSimpleFoam. Il codice di questo solver è stato ottenuto modificando 
manualmente quello del buoyantBoussinesqSimpleFoam, implementato di default in OpenFOAM, 
per tenere conto degli effetti aggiuntivi dell’umidità. Nella seconda fase entrano in gioco per ciascuna 
simulazione, oltre alle grandezze uscenti dal simpleFoam, la frazione massica di vapore sulla massa 
totale di vapore e aria secca (w_w), la temperatura (T), la pressione dinamica (p_rgh) e la diffusività 
termica (alphat). Questa seconda fase si arresta quando le grandezze coinvolte nel calcolo 
raggiungono valori costanti ed i residui si attestano su valori stabili.  
Entrambi i solver utilizzati sono di tipo steady-state, quindi la soluzione finale si ha quando i valori 
dei campi delle grandezze coinvolte sono stazionari, ovvero non variano più tra una iterazione e le 
successive. A quel punto le condizioni che identificano ogni cella del volume d’aria dello stadio
20 
 
possono essere considerate come le condizioni che si verificano con il funzionamento degli impianti 
di raffrescamento dell’aria a regime, dopo avere esaurito il transitorio di avviamento, e dunque sono 
pronte per essere manipolate ai fini della valutazione del comfort. 
3.4.3 Condizioni al contorno 
In questo paragrafo risulterà più chiara la definizione delle grandezze coinvolte nelle simulazioni, di 
cui si è accennato a paragrafo 3.4.2, nonché l’utilità dei gruppi di facce costruiti con Salome trattati 
al paragrafo 3.4.1.  
Intervenendo sulle condizioni al contorno si possono variare le condizioni di ogni simulazione, 
comprese quelle relative a portate, temperature ed umidità dell’aria di raffrescamento. 
3.4.3.1 Velocità U 
Per la velocità sono state scelte: 
• condizioni di tipo noSlip su tutte le pareti (Roof, Campo, SeduteInf, SeduteMed, SeduteSup); 
• condizioni di tipo flowRateInletVelocity sui gruppi di bocchette (BocchetteCampo, 
BocchetteInf, BocchetteMed, BocchetteSup). Questa condizione permette di rappresentare 
l’ingresso dell’aria condizionata nel volume d’aria attraverso le bocchette. In particolare per 
ogni gruppo di bocchette viene fissato secondo le esigenze, di simulazione in simulazione, 
un volumetricFlowRate costante in m
3
/s che rappresenta la portata di aria 
complessivamente emessa (ad esempio per BocchetteSup il volumetricFlowRate è pari a 225 
m
3
/s in una delle simulazioni, 200 m
3
/s in un’altra ecc.); 
• una condizione di tipo freestream per Sky, la faccia del volume in comunicazione con 
l’esterno. 
3.4.3.2 Temperatura T 
Per la temperatura sono state inserite: 
• condizioni di tipo zeroGradient sulle pareti Roof e Campo; 
• una condizione di tipo fixedValue su Sky con un valore costante fissato a 30°C, 
rappresentativo delle condizioni climatiche esterne; 
• condizioni di tipo fixedValue su BocchetteCampo, BocchetteInf, BocchetteMed, 
BocchetteSup. Per ciascuno di questi gruppi si è inserito, di simulazione in simulazione, un 
valore uniforme pari alla temperatura dell’aria condizionata immessa nel volume d’aria (ad
21 
 
esempio per BocchetteSup questo valore è pari a 19°C in una delle simulazioni, 20°C in 
un’altra ecc.); 
• condizioni di tipo fixedValue su SeduteInf, SeduteMed e SeduteSup. In questo caso si è scelto 
un valore costante pari a 37°C, che rappresenta idealmente la presenza degli spettatori 
distribuiti sulla superficie, considerandone la loro temperatura media corporea. 
3.4.3.3 Frazione massica di vapore w_w  
La frazione massica di vapore, definita come rapporto tra la massa di vapore e la massa totale di 
vapore più aria secca, è stata inserita nelle boundary calcolandola con la seguente formula: 
�� _�� = 
0,622 ∙ ф ∙ �� ������ ( �� )
101325− 0,378 ∙ ф ∙ �� ������ ( �� )
 
dove ф è l’umidità relativa e P sat(T) la pressione di saturazione in funzione della temperatura calcolata 
mediante interpolazione sulle tabelle del vapore saturo dell’acqua presenti in letteratura. 
Dunque per w_w sono state applicate: 
• condizioni di tipo zeroGradient per Roof, Campo, SeduteInf, SeduteMed, SeduteSup; 
• condizioni fixedValue con valori uniformi calcolati sulla base della temperatura e dell’umidità 
relativa per BocchetteCampo, BocchetteInf, BocchetteMed, BocchetteSup. Si noti che per 
tutte le mandate dell’aria, in tutte le simulazioni, si è scelta un’umidità relativa di 0,5. Questa 
è infatti considerata generalmente un buon parametro di umidità dell’aria in mandata negli 
impianti di condizionamento.  
• una condizione di tipo fixedValue per Sky, calcolata considerando un’umidità relativa pari a 
0,7 e una temperatura di 30°C, rappresentative delle condizioni climatiche esterne. 
3.4.3.4 Pressioni p e p_rgh 
La pressione atmosferica p e la pressione dinamica p_rgh presentano boundary conditions trattate 
identicamente, in particolare si hanno in ogni simulazione: 
• una condizione di tipo fixedValue uniformemente nulla sulla faccia Sky, corrispondente alla 
pressione ambientale (101325 Pa); 
• condizioni fixedFluxPressure uniformemente nulle su tutti gli altri gruppi di facce. 
3.4.3.5 Diffusività termica alphat 
Per la diffusività termica alphat sono state impostate:
22 
 
• condizioni di tipo calculated su BocchetteCampo, BocchetteInf, BocchetteMed, 
BocchetteSup e Sky; 
• condizioni di tipo alphatJayatillekeWallFunction (funzione di parete implementata in 
OpenFOAM) uniformemente nulle per tutti gli altri gruppi, con un numero di Prandtl pari a 
0,85.  
3.4.3.6 Energia cinetica turbolenta k  
L’energia cinetica turbolenta k sulle boundary è stata stimata utilizzando la formula proposta dal 
modello di turbolenza k-omega SST [10]: 
�� = 1,5 ∙ ( �� ∙ �� ������ )
2
 
con I intensità turbolenta considerata pari a 0,1 e U ref velocità di riferimento scelta pari a 0,5 m/s. 
Si hanno dunque per k: 
• condizioni kqRWallFunction (funzione di parete implementata in OpenFOAM) su Roof, 
Campo e sui tre gruppi di sedute. Il valore iniziale è risultato pari a 0,00375 m
2
/s
2
; 
• una condizione inletOutlet su Sky con valore iniziale fissato a 0,00375 m
2
/s
2
; 
• condizioni fixedValue sui gruppi di bocchette con un valore unifome pari a 0,001 m
2
/s
2
 
ricavato tenendo una U ref leggermente più bassa rispetto a 0,5 m/s. 
3.4.3.7 Dissipazione turbolenta omega 
Anche per stimare il coefficiente di dissipazione turbolenta omega sulle boundary si è utilizzata la 
formula proposta dal modello di turbolenza k-omega SST [10]: 
���������� =
�� 0,5
�� ����
0,25
∙ �� 
con C mu pari a 0,09 e la lunghezza di riferimento L (consiste in una dimensione rappresentativa del 
lato delle celle) considerata pari a 0,2 metri. 
Dunque sono state scelte: 
• condizioni di tipo omegaWallFunction (funzione di parete implementata in OpenFOAM), con 
un valore iniziale calcolato di 0,559 s
-1
 per Roof, Campo e per i gruppi di sedute;  
• una condizione inletOutlet per Sky con valore iniziale di 0,559 s
-1
; 
• condizioni fixedValue con un valore uniforme pari a 0,01 s
-1
 per BocchetteCampo, Bocchette 
Inf, BocchetteMed e BocchetteSup.