Relazione Finale con Allegati

Transcript

POR Campania 2000/2006 Misura 3.17 –
Bando per la concessione degli aiuti alle PMI
Metadistretto del settore ICT, di cui al d.d. n°52 del 03/03/2006.
Progetto “ Sistema informatico, di supporto per la valutazione
dell’impatto ambientale preventivo sulla qualità dell’aria
regionale da parte di nuovi insediamenti produttivi o di servizio”.
Partecipanti
ITM (Informatica Telematica Meridionale S.r.l.)
al Progetto:
Università degli Studi di Napoli Federico II
Dipartimento di Chimica
Pagina 1 di 44
RELAZIONE FINALE
PERIODO DAL 20/11/2009 AL 18/08/2010
ATS:
Tra ITM (Informatica Telematica Meridionale) S.r.l. e Dipartimento di Chimica
della Università degli Studi di Napoli “FEDERICO II” –
TITOLO DEL
PROGETTO:
“Sistema Informatico di supporto per la valutazione dell’Impatto Ambientale
preventivo sulla qualità dell’aria Regionale da parte di nuovi insediamenti
produttivi o di servizio”
COSTO
804.000,00 €
CONTRIBUTO
562.800,00 €
IMPRESA / ERP / Sede operativa:
1) I.T.M. S.r.l.
Via Nuova Poggioreale, 11 – 80143 NAPOLI
2) Dipartimento di Chimica
Università “Federico II”
Via Cinthia – Complesso Universitario Monte
Sant’Angelo 80126 - NAPOLI
1) STATO DI ATTUAZIONE DELL’INTERVENTO
Obiettivo Realizzativo 1
TITOLO OR 1
“Progettazione Direzione e Coordinamento”
1) Obiettivi raggiunti e scostamenti rispetto al progetto presentato. Eventuali criticità
Quest’obiettivo che si articola nella definizione del Programma di Ricerca e nel suo Piano di
Avanzamento è stato pienamente rispettato. In particolare il Programma di Ricerca è stato
sviluppato nel dettaglio, come previsto, nel primo mese di attività,
tenendo conto sia
dell’evoluzione tecnologica che della rimodulazione dei costi approvati. Per quanto riguarda il
Piano di Avanzamento, esso tiene conto dell’allungamento di alcune attività, dovuto anche ai ritardi
Pagina 2 di 44
delle procedure amministrative, coerentemente alla proroga concessa, prevedendo la fine di tutte le
attività al 18/08/2011 ed è stato monitorato per tutta la durata del progetto.
2) Descrizione delle attività svolte
L’attività di progettazione è stata sviluppata attraverso l’analisi di dettaglio dei processi di lavoro e
la loro pianificazione, in particolare sono stati :
- Definiti e pianificati l’intero Programma di Ricerca, analizzando obiettivi e risultati da
raggiungere;
- Definiti ed analizzati i singoli processi di ricerca;
- Definiti i requisiti tecnici dei poli di elaborazione e di rappresentazione ed i software relativi;
- Definite le aree funzionali d’intervento ed i modelli da implementare;
- Definita la campagna di rilevazione e sperimentazione.
In tutte queste fasi ha lavorato il personale della I.T.M., con competenze prettamente informatiche,
con il personale dell’Università, che ha portato la sua esperienza scientifica e di ricerca, sotto la
guida del responsabile scientifico Prof. Guido Barone, con il coordinamento tecnico dell’Ing.
Michele Gallo, consulente esterno esperto nella direzione di progetti complessi.
In particolare per la pianificazione delle campagne di misurazione ed elaborazione sono state
coinvolte già in questa fase le società esterne SISTEMA SERVIZI CONSULTING sas e
CERTITEC Scarl.
TITOLO OR 2
“Sviluppo Sistema di calcolo parallelo”
Lo sviluppo del Sistema di calcolo parallelo, inteso come progettazione, fornitura, installazione e
collaudo, è stato effettuato nei tempi previsti, come da verbale di Collaudo.
Le attività sono state svolte dal personale della I.T.M. sotto la guida del Responsabile Scientifico e
del coordinatore in stretto contatto con il personale delle ditte fornitrici.
Pagina 3 di 44
TITOLO OR 3
“Implementazione modelli”
Quest’obiettivo è senz’altro quello centrale e più impegnativo di tutto il Progetto e per il suo
raggiungimento è stato necessario un tempo maggiore di quanto inizialmente preventivato.
Quest’attività è iniziata con l’installazione del software applicativo realizzato ad hoc sulla base
delle specifiche del Dip.to di Chimica dell’Università FEDERICO II, effettuata dal personale della
I.T.M. in collaborazione con il personale della FEDERICO II in stretto contatto con le ditte
fornitrici. Sono stati, poi, necessari numerosi interventi, sia di testing che di implementazione per
arrivare ad un corretto funzionamento dei vari modelli (meteorologico su scala regionale, di
emissione, di dispersione e reazione) previsti dal Progetto.
TITOLO OR 4
“Validazione dei modelli di qualità dell’aria”
Questo obiettivo realizzativo ha rispettato pienamente le previsioni del Progetto, ma ha risentito
dell’allungamento dei tempi del OR3 a cui era in parte subordinato. (vedi diagramma piano attività)
Le attività relative a questo obiettivo hanno riguardato la validazione dei modelli ottenuti in OR3.
In particolare per gli scenari storici si sono utilizzate come base di partenza le Banche Dati ottenute
dal Consorzio ISPRA (ex ANPA) per la stima delle emissioni mensili di inquinanti per il territorio
della Regione Campania. Sono state quindi effettuate delle elaborazioni sul sistema di calcolo
parallelo, confrontandone successivamente i risultati con dati storici delle Centraline ARPAC.
Quest’attività ha visto impegnati i tecnici della I.T.M. sotto la guida del Coordinatore Tecnico, con
il supporto nella fase di confronto del personale dell’Università e del Responsabile Scientifico.
Pagina 4 di 44
Preliminarmente è stato configurato ed installato come previsto dal progetto, il laboratorio di misura
mobile, sul quale sono state poi effettuate le attività di calibrazione e testing. Queste attività hanno
visto impegnati, oltre ai tecnici I.T.M., gli specialisti delle società fornitrici dei servizi di ricerca
CERTITEC e SISTEMA SERVIZI CONSULTING, sotto la guida del Responsabile Scientifico e
dei Borsisti del Dipartimento di Chimica dell’Università.
Lo stesso gruppo di lavoro ha poi provveduto alla elaborazione di scenari realistici di inquinamento
atmosferico sulla Regione Campania utilizzando le banche dati e i programmi della catena WRF-EMEP-CHIMERE relativamente ad alcuni periodi della stagione autunnale 2010, e a quella estiva
del 2011. Parallelamente si è provveduto, in varie fasi, a realizzare mediante le strumentazioni di un
laboratorio mobile, una serie di rilevazioni ed elaborazioni atte a realizzare una banca dati delle
concentrazioni in atmosfera dei principali inquinanti gas e polveri, così come previsto dal Progetto,
necessarie per la successiva validazione degli scenari realistici.
TITOLO OR 5
“Elaborazione e Validazione di scenari di inquinamento simulati.”
Questo obiettivo realizzativo ha rispettato pienamente le previsioni del Progetto, ma ha risentito
dell’indispensabile allungamento dei tempi del OR3 a cui anch’esso era in parte subordinato.
L’OR qui presentato è stato quello di giungere alla elaborazione e validazione di Scenari di
inquinamento simulati in previsione di variazioni nelle condizioni di emissione dal territorio
regionale dovute a variazioni tecnologiche (motori per l’autotrazione, impianti di riscaldamento
civile e industriale) o a diverse normative o infine a nuovi insediamenti produttivi o di servizio.
Approfittando dell’allungamento dei tempi dell’OR3 e conseguentemente dell’OR4, si è preferito
sviluppare dei nuovi scenari realistici ed effettuare nuove campagne di misura in differenti
condizioni meteo-climatiche (primavera ed estate 2011) per una più estesa base di confronto per lo
sviluppo degli scenari simulati. Le campagne sperimentali condotte con il Laboratorio Mobile delle
società CERTITEC e SISTEMA SERVIZI CONSULTING sono state anche importanti per il
progressivo deterioramento della Rete Regionale di Centraline fisse dell’ARPAC. Lo scopo finale
dell’OR5 è stato quindi conseguito effettuando
Pagina 5 di 44
A)
tre simulazioni con l’utilizzo al solito la catena WRF-EMEP-CHIMERE, mantenendo
inalterate le condizioni meteorologiche (WRF) in tre differenti condizioni meteo reali e
invece forzando i dati emissivi reali degli stessi periodi mediante dei coefficienti
peggiorativi; il programma diffusivo e di trasformazione chimica e fotochimica CHIMERE
ha sviluppato le conseguenze di questa variazione simulata nelle emissioni di fondo del
territorio.
B)
due simulazioni utilizzando il programma semplificato WindImula per il calcolo delle
emissioni da una fonte puntiforme (Camino industriale), collocando virtualmente una fonte
emissiva con le caratteristiche note di un termovalorizzatore realmente in funzione, in un
sito di Napoli Est e sviluppando le ricadute al suolo di polveri sottili e di una miscela di
Inquinanti gassosi sul territorio circostante.
In tutti i casi i risultati dei due tipi di simulazioni sono risultati coerenti con le aspettative e hanno
soddisfatto pienamente l’analisi critica a posteriori degli stessi.
Queste attività hanno visto impegnati i tecnici I.T.M., sotto la guida del Coordinatore Tecnico del
personale del Dipartimento di Chimica dell’Università sotto la guida complessiva del Responsabile
Scientifico e delle società CERTITEC e SISTEMA SERVIZI CONSULTING.
TITOLO OR 6
“Sviluppo output di rappresentazione”
Questo obiettivo realizzativo è stato migliorato rispetto a quanto previsto nel Progetto iniziale. Si è
infatti rimodulato il dimensionamento delle attrezzature, sulla base dei costi approvati, utilizzando
per la rappresentazione grafica un software applicativo ad hoc ed in parte integrato con quello
necessario per l’elaborazione dei modelli di qualità dell’aria, migliorando le prestazioni
complessive della piattaforma tecnologica integrata e così realizzata.
Pagina 6 di 44
Le attività di questo obiettivo sono iniziate con l’installazione del software grafico da parte dei
tecnici I.T.M. con il supporto della ditta fornitrice, e vedono successivamente impegnato il gruppo
di lavoro, sotto la guida del Responsabile Scientifico e del Coordinatore tecnico per lo sviluppo
delle varie Rappresentazioni significative e l’Analisi dei Risultati.
Il lavoro svolto in questa fase, quindi, consisteva nell’installazione e configurazione del pacchetto
software relativo al “Modulo 3” del progetto, sviluppato sulla base delle indicazioni suggerite dal
Dipartimento di Chimica dell’Università degli Studi di Napoli “Federico II”. Tale pacchetto
software ha permesso di elaborare diverse tipologie di rendering dei dati di output ottenuti dalle
precedenti simulazioni. Tutti i software presenti nel pacchetto, sono stati ovviamente trattati
seguendo le istruzioni indicate nella documentazione ed i manuali forniti con lo stesso e installati
all’interno dell’ambiente di calcolo che ospita la catena modellistica utilizzata nel progetto.
Successivamente, sono stati riadattati e riconfigurati per il sistema di calcolo in base alle nostre
esigenze di rendering.
Infine, per semplificare e velocizzare il lavoro da parte dell’utente operatore circa la configurazione
e esecuzione dei moduli software forniti, è stata prevista un’interfaccia utente grafica user friendly
realizzata ad hoc, proprio allo scopo di non coinvolgere l’utente in tutta la complessità sottostante.
L’interfaccia, inoltre, fornisce una serie di opzioni per permettere una completa personalizzazione
dei dati che si desidera visualizzare e dare la possibilità, attraverso un sistema di filtri, di selezionare
le componenti di proprio interesse, come la visualizzazione di specifici inquinanti chimici, la data e
l’ora di interesse e altre opzioni.
Infine, è stato eseguito un lavoro di integrazione tra il modulo grafico appena installato e i
precedenti moduli 1 e 2 previsti dal progetto, cioè il Modello Meteo Regionale e il Modello di
dispersione e reazione degli inquinanti, entrambi sviluppati e configurati per la regione Campania.
Infine è stata effettuata un’analisi comparata e critica dei risultati ottenuti dagli scenari reali nelle
varie situazioni stagionali e sono stati sottolineati i vantaggi ottenibili rispetto allo stato attuale della
Rete Regionale delle centraline fisse ARPAC, in particolare nei momenti di disfunzionamento di
detta RR, e sono stati suggeriti miglioramenti riguardo al possibile potenziamento futuro della
stessa , proprio sulle risultanze dell’analisi dettagliata degli scenari reali o simulati prodotti.
La relazione è accompagnata da alcuni semplici DEMO che illustrano, mediante una selezione
molto limitata delle oltre 10.000 mappe regionali di inquinamento prodotte, le caratteristiche
evidenziate dalle stesse, utilizzabili per future applicazioni.
Pagina 7 di 44
ARTICOLAZIONE DELLE ATTIVITA’ REALIZZATE (controllare le ultime 3 colonne)
OBIETTIVI
ATTIVITA’
REALIZZATIVI
O.R.1
Progettazione,
1.1 Programma ricerca
1.2 Piano Avanzamento
Direzione e
TIPOLOGIA
(RI/SP)
IMPEGNO
Mese/persone
(Personale dipendente)
IMPEGNO
Mese/persone
(Person. non
dipendente)
ERP (Dip.
Chimica)
(Docenti +
Borsisti)
Mese/persone
RI
0.53
0.00
0.31 + 0,17
RI
7.61
1.03
0.71 + 8.40
RI
4.80
0,00
0.00 + 0.50
17.65
2.93
0.80 + 1.57
23.21
3.98
0.72 + 0.00
23.44
2.63
0.75 + 3.69
Coordinamento
O.R.2
2.1
Sviluppo Sistema
Il Sistema di Calcolo
Calcolo
O.R.3
Implementazione
Modelli
3.1 Modello Meteorologico
Regionale
3.2 Modello Emissione
3.3 Modello Dispersione e
Reazione
RI
RI
RI
O.R.4
Validaz. Mod.
4.1 Scenari Storici
RI
2,71
1,33
0.80 + 0.00
4.2 Laboratorio Mobile
RI
0.00
0.00
0.00 + 13.87
4.3 Banca Dati
RI
4,19
0.00
0.26 + 0.05
4.4 Scenari realistici
RI
12,91
1.95
0.00+ 0.00
5.1 Scenari di inquinamento
RI
1.23
1.30
0.00+ 0.00
1.07
0.00
0.00+ 0.00
Qualità Aria
(AQM)
5.2 Pianificazione
O.R.5
Campionamento e
Elaborazione e
Simulazione
Validazione di
scenari di
inquinamento
simulati
RI
5.3 Banca dati aggiornata
RI
2,25
0.00
0.00+ 0.00
5.4 Analisi dati
RI
2,04
0.00
0.00+ 0.00
2,03
0.83
0.00+ 0.00
RI
4,53
2,05
0.00+ 0.00
RI
27,89
8.42
0.00 + 0.00
5.5 Scenari inquinamento
simulato da nuovi
RI
insediamenti
O.R.6
6.1 Installazione modulo SW
Output
grafico
Rappresentazione
6.2 Tabella / Dati / Grafici /
Mappe
Pagina 8 di 44
6.3 Analisi dei Risultati
RI
2,36
0,00
0.00 + 2.00
CONSULENZE ATTIVATE
N.
ENTE ORGANISMO DI RICERCA
COSTO COMPLESSIVO
PROFESSIONISTA
DELLA CONSULENZA
1
Ing. Michele Gallo
50.000 euro
2
CERTITEC S.c.a.r.l.
100.000 euro
3
SISTEMA SERVIZI CONSULTING S.a.s.
50.000 euro
OGGETTO DELLA CONSULENZA
N.
SINTETICA DDESCRIZIONE DELLE ATTIVITA’ SVOLTE
1
Coordinamento tecnico del Progetto
2
Rilevazione ed elaborazione dati con laboratorio mobile (ETLBUS)
3
Configurazione laboratorio mobile e pianificazione campagna di rilevazione per
raccolta, analisi ed elaborazione dati (ETLBUS e DUSTSCAN)
Rilevazione ed elaborazione dati con laboratorio mobile (DUSTSCAN)
Supervisione e validazione per raccolta, analisi ed elaborazione dati (ETLBUS)
Pagina 9 di 44
RISULTATI OTTENUTI
Installazione, collaudo e testing dell’ Hardware per la piattaforma HPC.
Nell’ambito del progetto è stata installata, collaudata e testata, sulle macchine dell’ITM, una
piattaforma operativa costituita da un sistema distribuito di nodi, allo scopo di creare un Cluster di
tipo Beowulf di High Performance Computing (HPC), dedicato al calcolo parallelo massivo.
L’architettura Beowulf è stata scelta in quanto è attualmente considerata l’architettura standard per
lo sviluppo di soluzioni di clustering inteso come insieme di computer ad alte prestazioni (in
alternativa alle soluzioni HPC proposte dai Supercomputer). Inoltre è una soluzione ottimale nel
caso in esame, in quanto è ideale per eseguire applicazioni di calcolo parallelo. Inoltre, il rapporto
costo/prestazioni di una macchina di tipo Beowulf è circa tre volte migliore di quello dei
tradizionali Supercomputer. Questa architettura è, infine, facilmente scalabile e permette di
semplificare il lavoro di realizzazione e configurazione di tutto l’ambiente Cluster.
Il sistema è finalizzato all’ottenimento di mappe e rappresentazioni grafiche della diffusione e
dispersione nell’atmosfera della Campania dei principali inquinanti gassosi e delle polveri sottili.
Sono stati quindi messi a punto dei Prototipi per la presentazione di questi scenari organizzati in
Domini geografici:

Il primo dominio ha risoluzione 9x9 km ed è centrato su tutta l’Italia. Questo dominio rappresenta
quello relativo al calcolo delle condizioni al contorno della simulazione.

Il secondo dominio, con risoluzione 3x3 km, è centrato sulla regione Campania e la può
rappresentare graficamente dalla latitudine 13,4 a 14,9° Est e dalla longitudine 40,3 a 41,3 ° Nord.
Questo dominio utilizza le condizioni al contorno, ottenute dall’elaborazione del primo dominio, e
permette di elaborare le nuove condizioni al contorno del dominio a risoluzione maggiore.

Il terzo dominio, con risoluzione maggiore 1x1 km, è sempre centrato sulla regione Campania, ma
può essere utilizzato per eventuali sviluppi riguardanti un dominio di elaborazione della simulazione
più dettagliato centrato su Napoli o altri siti particolari della regione.
Adattamento del modello Meteorologico WRF- ARW alle esigenze della produzione di scenari
di inquinamento.
Nell’ambito del progetto di ricerca, il software applicativo sviluppato ed opportunamente
implementatato ed adattato alle caratteristiche delle macchine dell’’Azienda permette di effettuare
Pagina 10 di 44
delle accurate simulazioni per analisi atmosferiche e previsioni meteorologiche. È applicabile su
porzioni di territorio estese da pochi metri fino a migliaia di chilometri, a diverse risoluzioni spaziotemporali. Tale software si basa sul modello open source Weather Research and Forecasting Model
(WRF), modello scelto per la sua elevata flessibilità che lo rende idoneo per molteplici utilizzi. Per
tale motivo il software in esame non è solo un tool per le previsioni meteorologiche, ma può anche
essere utilizzato per casi di studio di inquinamento, in quanto può fornire previsioni sia in tempo
reale, sia per riprendere e ricostruire dati storici, per la modellazione climatica su scala regionale e
quindi può essere utilizzato per la previsione del trasporto e della trasformazione chimico-fisica
degli inquinanti, ecc...
Architettura
Il WRF è composto da diversi moduli a partire dal pre-processing di diversi tipi di dati, fino
all'elaborazione degli output e post-processing grafico. Si distinguono due principali moduli, quello
del pre-processing (WPS) e quello che costituisce il nucleo del sistema modellistico (WRF-ARW),
ciascuno suddiviso in ulteriori moduli. Per ciascuno di questi moduli è stato realizzato uno script di
automazione che si occupa di eseguire il relativo modulo.
Nell’ambito della catena modellistica, l'utilizzo di questo software così adattato consiste nella
creazione di file di dati meteorologici come input necessari ai dati dei file di emissione
EMEP/ISPRA e al software di dispersione e trasformazione chimica CHIMERE. I file di dati
prodotti da WRF possono riassumersi in:

Campi tridimensionali della velocità del vento;

Campi tridimensionali del tensore della diffusione turbolenta;

Campi bidimensionali della velocità di frizione;

Campi bidimensionali dell'altezza di mescolamento;

Campi bidimensionali dell'altezza di rugosità del suolo;

Campi bidimensionali della radiazione solare totale.
Implementazione e adattamento dei software per l’utilizzo delle Banche dati EMEP da
inserire nella catena modellistica WRF-EMEP-CHIMERE per la produzione di scenari di
inquinamento.
L’EMEP, è un gruppo di esperti creato in seno all’Agenzia Europea per l’Ambiente (EEA), per
predisporre la guida per la compilazione degli inventari delle emissioni, guida che è finalizzata a
Pagina 11 di 44
facilitare la risoluzione dei problemi di inquinamento transfrontaliero attraverso la cooperazione
internazionale sul monitoraggio e la modellazione della qualità dell’aria, la redazione di inventari
delle emissioni e la loro proiezione al futuro per le valutazioni integrate. Ciascuno stato sottomette i
propri dati secondo le direttive diramate e periodicamente aggiornate dall’EMEP. I dati nazionali
subiscono un iter di controllo ed elaborazione per valutare la completezza dei dataset inviati e la
comparabilità del dataset rispetto a quelli equivalenti e sottomessi dallo stesso stato membro per la
compilazione dell’inventario precedente. Nell’adattamento alle esigenze del presente progetto si è
posta attenzione alle incongruenze segnalate dalle fonti Europee e italiane per ciascuna serie di dati,
scartandoli ove necessario. Ulteriori controlli sono stati eseguiti valutando la comparabilità dei dati
tra stessi settori e attività che producono quel tipo di emissioni (trasporti stradali ed extrastradali,
processi industriali, combustione industriale, combustione civile, emissioni biogeniche). Queste
sorgenti infatti costituiscono la maggior parte delle emissioni della Regione Campania. I dati di
output di questo software così implementato e testato hanno costituito l’input per il modello
CHIMERE.
Implementazione e adattamento della catena modellistica WRF-EMEP-CHIMERE alle
esigenze della produzione di scenari di inquinamento.
La catena modellistica (WRF-EMEP-CHIMERE), implementata nell’ambito del progetto, richiede
diversi tipi di dati per la simulazione di scenari di dispersione di inquinanti atmosferici. In
particolare, il modello Chimere necessita di tre tipi di dati di input: dati meteorologici (forniti dal
modello meteorologico WRF-ARW qui implementato e adattato), dati di emissione (ottenibili dalle
Banche dati e dai Modelli EMEP/ISPRA), e dati sugli aerosol come condizione al contorno. Tutti
questi dati vanno forniti su griglie regolari e in formati determinati. In questo progetto POR 3.17
sono state prodotte e sviluppate le operazioni specifiche che debbono essere svolte per ottenere e
trasformare nel formato necessario al modello Chimere, i dati di emissione derivanti da banche dati
pre-esistenti.
Nell’ambito delle prime fasi del Progetto ITM474529 del POR 3.17 sono stati quindi messi a punto
e utilizzati i modelli previsti dal progetto e relativi all’elaborazione e simulazione di scenari di
impatto ambientale nella regione Campania:
1) Il Modello Meteo Regionale configurato ad hoc per la regione Campania;
2) il Modello di emissione EMEP dedotto per la Campania;
Pagina 12 di 44
3) il Modello di dispersione e reazione degli inquinanti.
L’utilizzo del SW applicativo installato ed opportunamente implementato nell’ambito del Work
Package WP3 ha quindi consentito di produrre un primo scenario realistico relativo al mese di
ottobre 2010. I risultati sono stati confrontati soddisfacentemente con i dati registrati dalle
Centraline ARPAC in ambito urbano (Napoli e altri Capoluoghi). Lo scenario per altro ha fornito
interessanti e dettagliati risultati, a scansione oraria, su altri siti regionali (Città non Capoluoghi
provinciali, in particolare il sito di Acerra, nodi autostradali, assi di grande viabilità etc.).
Sono stati contestualmente ottenuti i seguenti ulteriori risultati:
- Organizzazione e messa in disponibilità di una Banca Dati relativa alle emissioni fino al 2007
per l’Italia e la Campania (da EMEP/ISPRA).
- Produzione della raccolta delle Mappe di emissione sintetiche 2010 e 2011 per l’Italia, come
griglie 0.5° x 0.5° (proiezione secondo Mercatore) e 50 x 50 km.
- Produzione di una Banca Dati delle emissioni per l’Italia (dal Consorzio ISPRA) e delle
emissioni mensili, stimate con fattori differenziali stagionali, per la Campania per il 2009,
2010 e 2011.
Nelle fasi successive per la raccolta, elaborazione ed analisi dei dati si segnalano alcuni
risultati significativi:
- Messa a punto e calibrazione della strumentazione per il monitoraggio delle polveri sottili e
dei principali inquinanti gassosi assemblati in due versioni: una a bordo di un furgone
attrezzato, l’altra in versione portatile. I furgoni sono stati utilizzati in alcune Campagne di
monitoraggio come postazione mobile sorvegliate o anche come supporto per il trasporto e
l’installazione delle strumentazioni in versione portatile in siti protetti (presso Edifici Pubblici
o Privati).
- Produzione di una Banca Dati delle misure riportate in rete dalle Centraline ARPAC per
giorni selezionati, alcuni consecutivi, per i mesi interessati negli anni 2009-2010-2011,
- Campagne di misure di polveri sottili (sistema DUSTSCAN) e produzione della banca dati
relativa con la determinazione del PM10 in 9 siti urbani della Città di Napoli, in 5 siti della
Pagina 13 di 44
Provincia di Benevento (Capoluogo incluso) e in 2 siti di Acerra. (Tabelle delle medie e delle
medie corrette di PM10 /periodo orario e dati di Temperature, Pressioni e Umidità relativa. //
Raccolta dei grafici rappresentativi delle misure ).
- Campagne di misure (sistema ETL BUS), produzione della banca dati relativa con
medie giornaliere, di CO, NO2 e O3) nei siti urbani della Città di Napoli (zone collinari e
residenziali, zone di traffico) in alcuni siti della Provincia di Napoli vicino ai raccordi
autostradali, in alcuni siti della Provincia di Caserta in zona industriale e vicino ai
raccordi autostradali.
L’elaborazione degli scenari sia realistici che simulati, grazie all’efficacia della piattaforma
informatica
realizzata,
ha
prodotto
un’abbondanza
di
risultati
dando
origine
complessivamente, tenendo conto anche degli scenari simulati in versione “PAR O” (con
fattore moltiplicativo quasi 0), a circa 22.000 mappe solo per il DOM 3, tutte di lettura
abbastanza immediata (vedi CD allegato).
Conferma della validità e affidabilità della Metodologia Modellistica
I dati riportati nell’analisi degli scenari, per quello che riguardano i valori massimi, si riferiscono ad
aree del territorio Campano distanti dai Capoluoghi. I valori minori delle simulazioni si riferiscono
invece ai Capoluoghi di Provincia o ad Acerra. Gli scenari in realtà danno gli andamenti ora per ora
per i vari giorni con evidenti punte di massima nelle ore del tardo pomeriggio e della sera. Essi
altresì tengono conto delle reali condizioni meteorologiche per cui i massimi più accentuati
vengono riscontrati nei periodi secchi anche invernali, mentre tendono ad abbassarsi, almeno per il
PM10, nei giorni di pioggia e nelle ore più piovose.
Pagina 14 di 44
Complessivamente quindi si può ben ritenere che i dati forniti dagli Scenari sviluppati con le
Metodologie e i Programmi presentati in questo Progetto siano del tutto coerenti con i limitati dati
forniti dalle centraline urbane fisse. Gli Scenari per altro mostrano l’esistenza di dati di
inquinamento più accentuati di quelli misurati nelle città e che si presentano in particolare sui
principali assi viari della Regione e sui Distretti industriali dove non vi sono strumentazioni per il
monitoraggio continuo dell’inquinamento. Inoltre gli Scenari forniscono un quadro molto più
dettagliato, non solo spaziale, ma anche nella sua evoluzione oraria nel corso delle singole giornate.
In conclusione si può affermare che complessivamente gli Scenari prodotti con il programma
utilizzato sono stati validati soddisfacentemente nel periodo invernale e semiprimaverile:
l’applicazione nei periodi successivi è quindi del tutto soddisfacente e potrà essere utilizzato anche
per produrre previsioni.
Ciò è dimostrato sia dal confronto giornaliero con i dati delle Centraline fisse ARPAC, sia da quello
con le misure sperimentali effettuate tramite le strumentazioni limitate del Laboratorio Mobile
impiegato in questo Progetto.
D’altra parte si deve sottolineare che la disposizione delle Centraline ARPAC solo in alcuni
quartieri dei Capoluoghi urbani porta a sottovalutare i dati di inquinamento di intere aree della
Regione, lontane dalle aree urbane.
D'altra parte, i dati delle Centraline ARPAC dei Capoluoghi effettuano, come già sottolineato,
medie giornaliere ed i minimi precedenti si riferiscono quasi sempre a orari di punta (primo
pomeriggio) e al solito in aree relativamente lontane dai siti ove operano le Centraline stesse.
Confronti interstagionali per PM10 e per ciascuno degli inquinanti gassosi
Gli scenari forniscono delle rappresentazioni molto dettagliate, essendo riportate per ogni ora del
giorno con una accuratezza relativa ad aree di 1 km x 1 km.
In tutto i periodi valutati non risultano comunque sforamenti degli Standard di Qualità dell’Aria
come dalle normative di Legge previste per stimare il grado di pericolosità dell’inquinamento
(D.M. no. 60 del 2/04/2002 che recepisce le Direttive Europee, e sostituisce i precedenti del
1992/94).
Pagina 15 di 44
Conclusione
Si può affermare che complessivamente gli Scenari prodotti con il programma utilizzato sono stati
collaudati soddisfacentemente e quindi le differenze stagionali nelle Qualità dell’Aria sono ben
evidenziate per alcune sostanze, mentre, come era da aspettarsi, per altre risultano differenze
irrilevanti.
Complessivamente quindi si può ben ritenere che i dati forniti dagli Scenari sviluppati con le
Metodologie e i Programmi presentati in questo Progetto siano del tutto coerenti con le aspettative.
Gli Scenari per altro mostrano l’esistenza di dati di inquinamento spesso più accentuati di quelli
misurati nelle città e che si presentano in particolare sugli Assi viari principali della Regione e sui
Distretti
industriali
dove
non
vi
sono
strumentazioni
per
il
monitoraggio
continuo
dell’inquinamento. Inoltre gli Scenari forniscono un quadro molto più dettagliato, non solo spaziale,
ma anche nella sua evoluzione oraria nel corso delle singole giornate. Gli scenari infine tengono ben
conto delle condizioni meteorologiche per cui i massimi più accentuati vengono riscontrati nei
periodi secchi o poco ventosi, mentre tendono ad abbassarsi, nei giorni di pioggia e nelle ore più
piovose.
Analisi di casi estremi imprevisti (incendi anche diffusi, incidenti) segnalati dalla
Rete Regionale di Stazioni o Centraline fisse dell’ARPAC
L’analisi dei risultati prodotti dai calcoli della catena WRF-EMEP-CHIMERE ha mostrato in alcuni
casi delle differenze tra i dati di inquinamento calcolati e quelli misurati dalle Centraline fisse e/o
dal Laboratorio Mobile utilizzato in questo Progetto.
La conclusione è che in questi pochi casi particolari la capacità revisionali sono venute meno perché
il modulo EMEP, che stima le emissioni regionale e provinciali, non ha potuto prevedere incendi
anche diffusi ad esempio di roghi stradali di sacchetti di immondizia innescati dalla popolazione di
alcuni quartieri di Napoli o di alcuni Comuni. Oppure roghi di cumuli di copertoni di ruote di auto e
tir in località extraurbane; o infine di fuochi utilizzati dai ladri di cavi di rame per bruciarne le
vernici isolanti.
Critica della attuale situazione carente della R.R.
In questa situazione i risultati della catena di calcolo WRF-EMEP-CHIMERE possono esercitare un
valido ruolo di supplenza, purchè siano gestiti da personale a conoscenza del know-how.
Potenzialità dell’analisi: monitoraggio di aree non coperte dalla Rete Regionale
Un’altra capacità di analisi della catena WRF-EMEP-CHIMERE è rappresentata dalla possibilità di
Pagina 16 di 44
calcolare l’inquinamento da polveri sottili e da sostanze gassose, previste dalle Normative di Legge,
anche in aree non coperte dalla Rete Regionale di Centraline fisse, oltre alla possibilità di
arricchirne le corrispondenti Banche dati a disposizione delle Autorità locali o di potenziali utenti.
Potenzialità predittiva degli scenari
Nel modulo WP5-5 è stata dimostrata la concreta capacità della catena WRF-EMEP-CHIMERE di
simulare le conseguenze di variazioni nella tecnologia delle emissioni complessive o per settori
definiti (industria, servizi, traffico) o per l’installazione di nuovi impianti (emissione,
trasformazione e ricaduta al suolo di inquinanti da sorgenti locali puntiformi
Capacità di valutare la Qualità dell’Aria a breve(oggi/domani/dopodomani)
E’ possibile in principio non limitarsi a fare delle previsioni meteorologiche, anche locali, come è
possibile già oggi, ma utilizzare la catena WRF-EMEP-CHIMERE per effettuare delle previsioni
realistiche a breve (oggi/domani/dopodomani) sullo stato dell’inquinamento atmosferico e della
Qualità dell’aria.
Utilizzabilità e Commerciabilità dei prodotti
Non è qui il luogo per effettuare una valutazione di marketing, ma una brevissima considerazione
sulla utilizzabilità dei risultati di questo progetto va fatta. In realtà, oltre ovviamente alla Regione
Campania, possono essere interessati tutti gli altri Enti pubblici (Comuni, Aree Metropolitane,
Provincie, fintanto che
rimarranno in vita, o eventuali Organi intermedi che le dovessero
sostituire), sia campani che di altre Regioni e Autorità locali, ma anche altri Enti di servizio,
Aziende e strutture produttive potranno a loro volta essere interessate.
Napoli 18/08/2011
Ing. Michele Gallo
____________________
Prof Guido Barone
____________________
Pagina 17 di 44
INDICE - ALLEGATI
Elenco Deliverables ........................................................................................................................... 19
Il Diagramma di Gantt ....................................................................................................................... 20
Checklist di Valutazione .................................................................................................................... 25
Formulazione dei criteri di dimensionamento e attività di collaudo della piattaforma di calcolo
parallelo (HPC) .................................................................................................................................. 33
Collaudo della piattaforma HPC - Hardware ..................................................................................... 39
Collaudo della piattaforma HPC - Software ...................................................................................... 40
Configurazione Laboratorio Mobile ETLBUS e DUSTSCAN ......................................................... 41
Analisi del materiale grafico prodotto ............................................................................................... 44
Selezione di alcune mappe degli scenari elaborati............................................................................. 44
Pagina 18 di 44
ELENCO DELIVERABLES
Denominazione
Deliverable
WP/Task
Mese
Data
inizio ultimazione
Inizio
20.11.2009
D1
Programma di ricerca
WP 1/Task 1.1
30/11/2009
D2
Piano avanzamento lavori
WP 1/Task 1.2
31/07/2011
D3
Sistema di calcolo parallelo
WP 2/Task 2.1
1
31/01/2010
D4
Modello meteorologico regionale
WP 3/Task 3.1
2
30/06/2010
D5
Modello di emissione
WP 3/Task 3.2
4
31/10/2010
D6
Modello di dispersione e reazione
WP 3/Task 3.3
31/10/2010
D7
Scenari storici di inquinamento
WP 4/Task 4.1
5
5
8
D8
Laboratorio mobile
WP 4/Task 4.2
1
30/04/2010
D9
Banca dati (da rilevazione mobile)
WP 4/Task 4.3
31/03/2011
D10
Scenari realistici di inquinamento
WP 4/Task 4.4
8
10
11
D11
Scenari di inquinamento
WP 5/Task 5.1
18
30/06/2011
D12
Prog. delle attività di campionamento e
WP 5/Task 5.2
18
30/07/2011
D13
WP 5/Task 5.3
18
31/07/2011
D14
Banca
dati aggiornata
sssimulazione
Analisi dati
WP 5/Task 5.4
18
31/07/2011
D15
Scenari di inq.nto simulato da nuovi
WP 5/Task 5.5
18
31/07/2011
D16
WP 6/Task 6.1
10
30/11/2010
D17
Sistema
grafico
insediamenti
Tabelle / Dati / Grafici / Mappe
WP 6/Task 6.2
10
18/08/2011
D18
Analisi dei Risultati
WP 6/Task 6.3
10
18/08/2011
31/12/2010
30/05/2011
Pagina 19 di 44
Milestones
Nr.
Denominazione
WP/Task
Data ultimazione
WP 2/Task 2.1
31/01/2010
WP 3/Task 3.1
30/06/2010
M3 Verifica equipaggiamento laboratorio mobile
WP 4/Task 4.2
31/10/2010
M4 Verifica sistema grafico
WP 6/Task 6.1
30/11/2010
M5 Verifica scenari storici
WP 4/Task 4.1
31/12/2010
M6 Verifica scenari realistici
WP 4/Task 4.4
30/04/2011
M7 Elaborazione Scenari di inq.nto simulato
WP 5/Task 5.5
31/07/2011
M8 Verifica grafici e mappe
WP 6/Task 6.2
18/08/2011
M1 Collaudo sistema calcolo parallelo
M2
Elaborazione modello meteorologico
regionale
Pagina 20 di 44
IL DIAGRAMMA DI GANTT
Il diagramma di Gantt rappresenta l’organizzazione temporale delle attività descritte nel nuovo
programma di ricerca. Pertanto, le attività di riferimento risultano suddivise in WP (workpackages), ciascuno articolato in Task.
Il Gantt è suddiviso in mesi numerati, dal mese n°1, corrispondente a Dicembre 2009 (che
comprende l’arco temporale che va dall’ 01/12/2009 al 31/12/2009) al mese n°21, corrispondente a
Luglio 2011 (che comprende l’arco temporale che va dall’ 01/08/2011 al 18/08/2011). Il diagramma
parte dalla data di inizio progetto, corrispondente al 20/11/2009.
Il WP1 , corrispondente all’attività di Progettazione, direzione e coordinamento, si sviluppa per
tutta la durata del progetto, prevedendo riunioni operative con frequenza almeno settimanale.
Il WP1 è articolato nei seguenti Task:
Task 1.1 - Programma di ricerca  sviluppato nell’arco temporale che va dall’inizio del progetto
(20/11/2009) al 30/11/2009
Task 1.2
Piano di avanzamento  sviluppato per tutta la durata del progetto
Il WP2 , corrispondente all’attività di Sviluppo del sistema di calcolo, si articola nel solo Task 2.1
“Il sistema di calcolo” che si sviluppa nell’arco temporale che va dall’ 1/12/2009 al 31/01/2010.
Il WP3 , corrispondente all’attività di Implementazione dei modelli, si sviluppa nell’arco temporale
che va dal 01/01/2010 al 31/10/2010.
Il WP3 sarà articolato nei seguenti Task:
Task 3.1 Modello meteo regionale 
sviluppato nell’arco temporale che va dal 01/01/2010 al
30/06/2010.
Task 3.2
Modello di emissione

31/10/2010.
Task 3.3 Modello di dispersione e reazione  sviluppato nell’arco temporale che va dal
01/04/2010 al 31/10/2010.
Il WP4 , corrispondente all’attività di Validazione del modello di qualità dell’aria, si sviluppa
nell’arco temporale che va dal 01/06/2010 al 30/04/2011.
Pagina 21 di 44
Task 4.1
Scenari storici

31/12/2010.
Task 4.2 Laboratorio mobile  sviluppato nell’arco temporale che va dal 01/12/2010 al
31/12/2010.
Task 4.3
Banca dati

30/04/2011.
Task 4.4
Scenari realistici

30/04/2011.
Il WP5 , corrispondente all’attività di Elaborazione / Validazione scenari simulati, si sviluppa
nell’arco temporale che va dal 01/05/2011 al 31/06/2011.
Task 5.1 Scenari inquinamento
 sviluppato nell’arco temporale che va dal 01/05/2011
al 30/06/2011
Task 5.2 Programma di Campionamento e simulazione  sviluppato nell’arco temporale
che va dal 01/05/2011 al 30/06/2011
Task 5.3 Banca dati
 sviluppato nell’arco temporale che va dal
01/05/2011 al 31/07/2011
Task 5.4 Risultato analisi
01/05/2011 al 31/07/2011
Task 5.5 Scenari di inquinamento
simulati da nuovi insediamenti
 sviluppato nell’arco temporale che va dal simulato
01/05/2011 al 31/07/2011
Il WP6 , corrispondente all’attività di Output rappresentazione, si sviluppa nell’arco temporale che
va dal 01/09/2010 al 18/08/2011.
Pagina 22 di 44
Task 6.1 Installazione modello SW grafico  sviluppato nell’arco temporale che va dal
01/09/2010 al 30/11/2010
Task 6.2 Tabelle dati, grafici e mappe
01/09/2010 al 18/08/2011
Task 6.3 Analisi dei risultati
01/09/2010 al 18/08/2011
Infine, le Milestones, introdotte nel nuovo programma di ricerca sono state introdotte nel
Diagramma di Gantt attraverso la numerazione introdotta nel campo “Nr”della tabella seguente:
Milestones
Nr.
Denominazione
WP/Task
Data ultimazione
WP 2/Task 2.1
31/01/2010
WP 3/Task 3.1
30/06/2010
M3 Verifica equipaggiamento laboratorio mobile
WP 4/Task 4.2
31/10/2010
M4 Verifica sistema grafico
WP 6/Task 6.1
30/11/2010
M5 Verifica scenari storici
WP 4/Task 4.1
31/12/2010
M6 Verifica scenari realistici
WP 4/Task 4.4
30/04/2011
M7 Elaborazione Scenari di inq.nto simulato
WP 5/Task 5.1
31/07/2011
M8 Verifica grafici e mappe
WP 6/Task 6.2
18/08/2011
M1 Collaudo sistema calcolo parallelo
M2
Elaborazione modello meteorologico
regionale
Pagina 23 di 44
Consuntivo
Allegato WP1-7
al 18.08.2011
Anno 2009
Anno 2010
Elemento
M1
Cod.
Attività di Riferimento
Progettaz. Direz. & Coord.
MESE
NOV
dal-al
20/11/09
Task 1.1
Piano Avanzamento
Task 1.2
Il Sistema di Calcolo
Implementazione Modelli
M6
M7
M8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
DIC
GEN
FEB
MAR
APR
MAG
GIU
LUG
AGO
SETT
OTT
NOV
DIC
GEN
FEB
MAR
APR
MAG
GIU
LUG
AGO
28/02/10
31/03/10
30/04/10
31/05/10
30/06/10
30/09/10
31/10/10
30/11/10
31/12/10
31/12/09 31/01/10
31/07/10 31/08/10
31/01/11 28/02/11
31/03/11 30/04/11
31/05/11 30/06/11 ########
18/08/11
WP3
Modello Emissione
Task 3.2
Modello Dispersione e Reaz.
Task 3.3
WP4
Scenari Storici
Task 4.1
Laboratorio Mobile
Task 4.2
Banca Dati
Task 4.3
Scenari Realistici
Task 4.4
WP5
Scenari di Inquinamento
Task 5.1
Pianificazione Campionamento e Simulazione
Task 5.2
Banca Dati aggiornata
Task 5.3
Analisi dati
Task 5.4
Scenari Inq.nto simulato da nuovi insediamenti
Task 5.5
Output Rappresentazione
M5
WP2
Task 3.1
Elaboraz./Validaz. Scenari Simulati
M4
Tasl 2.1
Modello Metereologico Regionale
Validaz. Mod. Qualità Aria (AQM)
M3
WP1
Programma ricerca
Sviluppo Sistema Calcolo
Anno 2011
M2
WP6
Installazione modulo SW grafico
Task 6.1
Tabella / Dati / Grafici / Mappe
Task 6.2
Analisi dei Risultati
Task 6.3
Prof.
Totale Risorse Umane per Mese
Borsisti
Pagina 24 di 44
CHECKLIST DI VALUTAZIONE
Sviluppo Sistema Calcolo Parallelo
WP: 2
Task: 2.1
Milestone: M1
Configurazione, Installazione e Testing Sistema
Collaudo Sistema Calcolo Parallelo
Deliverable
Codice:
Denominazione:
D.3
Sistema di calcolo parallelo configurato e testato
GOAL:
Id
1.
QUESTION
Superamento items di Collaudo
Misura Attesa
collaudo positivo
≥ 80% items
Misura Riscontrata
100%
2.
3.
4.
5.
6.
..n
Esito valutazione
Data:31/01/2010
Firme:
Pagina 25 di 44
Sviluppo output di rappresentazione
WP: 3
Task: 3.1
Milestone: M2
Configurazione, Installazione e Testing Sistema
Elaborazione modello meteorologico regionale
Deliverable
Codice:
Denominazione:
D.4
Modello meteorologico regionale
GOAL:
Id
1.
QUESTION
Verifica modello meteorologico su
scala regionale correttamente elaborato
Misura Attesa
Modelli elaborati
≥2
Misura Riscontrata
3 elaborazioni WRF di
prova (i risultati non
essendo utili per le fasi
successive del progetto
non sono stati salvati)
2.
3.
4.
5.
6.
..n
Esito valutazione
Data:30/06/2010
Firme:
Pagina 26 di 44
Validazione modello qualità dell’aria
WP: 4
Task: 4.2
Milestone: M3
Configurazione, Installazione e Testing
Laboratorio mobile
Verifica equipaggiamento laboratorio mobile
Deliverable
Codice:
Denominazione:
D.8
Laboratorio mobile
GOAL:
Id
1.
QUESTION
Rispondenza equipaggiamento alle
specifiche
Misura Attesa
Verifica positiva
= 100%
Misura Riscontrata
100% ETLBUS
100% DUTSCAN *
* (collaudo effettuato
il 10/12/2009)
2.
3.
4.
5.
6.
..n
Esito valutazione
Data:31/10/2010
Firme:
Pagina 27 di 44
Validazione Modello Qualità dell’aria
WP: 4
Task: 4.1
Milestone: M5
Elaborazione scenari storici di inquinamento
Verifica scenari storici
Deliverable
Codice:
Denominazione:
D.7
Scenari storici di inquinamento
GOAL:
Id
1.
QUESTION
Misura Attesa
Misura Riscontrata
Verifica n° Scenari storici significativi Scenari storici
Elaborati 3 scenari
correttamente elaborati
significativi
storici di prova con dati
correttamente elaborati del 07/2003
≥2
2.
3.
4.
5.
6.
..n
Esito valutazione
Data: 31/10/2010
Firme:
Pagina 28 di 44
Validazione modello qualità dell’aria
WP: 4
Task: 4.4
Milestone: M6
Aggiornamento ed Elaborazione scenari realistici
Verifica scenari inquinamento reale
Deliverable
Codice:
Denominazione:
D.10
Scenari realistici di inquinamento
GOAL:
Id
1.
QUESTION
Verifica scenari realistici di
inquinamento significativi
Misura Attesa
Scenari realistici di
inquinamento
significativi
≥5
Misura Riscontrata
9:
6-9/10/2010
15-20/12/2010
25-30/12/2010
2-7/01/2011
26-31/01/2011
31/01 – 6/02/2011
01-08/03/2011
08-15/03/2011
16-23/03/2011
2.
3.
4.
5.
6.
..n
Esito valutazione
Data: 31/03/2011
Firme:
Pagina 29 di 44
WP: 6
Task: 6.1
Milestone: M4
Sviluppo sistema informatico di
rappresentazione
Installazione modulo SW grafico
Verifica sistema grafico
Deliverable
Codice:
Denominazione:
D.16
Sistema grafico
GOAL:
Id
1.
QUESTION
Verifica SW grafici
Misura Attesa
Grafici correttamente
elaborati > 2
Misura Riscontrata
> 100
2.
3.
4.
5.
6.
..n
Esito valutazione
Data: 30/11/2010
Firme:
Pagina 30 di 44
Elaborazione e validazione scenari di
inquinamento simulato
Elaborazione e validazione scenari simulati
WP: 5
Task: 5.5
Milestone: M7
Verifica scenari di inquinamento simulati
Deliverable
Codice:
Denominazione:
D.15
Scenari di inquinamento simulati
GOAL:
Id
1.
QUESTION
Verifica scenari simulati significativi
Misura Attesa
Scenari simulati
significativi
≥5
Misura Riscontrata
5:
15-20/12/2010
25-30/12/2011
04-08/07/2011
30/06/2011
01/07/2011
2.
3.
4.
5.
6.
..n
Esito valutazione
Data: 30/07/2011
Firme:
Pagina 31 di 44
WP: 6
Task 6.2
Milestone: M8
Sviluppo Sistema informatico di
rappresentazione
Sviluppo grafici e mappe
Verifica tabelle dati, grafici e mappe
Deliverable
Codice:
Denominazione:
D.17
Tabelle dati, grafici, mappe cartografiche
GOAL:
Id
1.
QUESTION
Misura Attesa
N° grafici e n° mappe significative per N° grafici e n°mappe
singolo scenario analizzato (reali e
significative per
simulati)
singolo scenario
≥30
Misura Riscontrata
600 per un totale
> 10000
2.
3.
4.
5.
6.
..n
Esito valutazione
Data: 18/08/2011
Firme:
Pagina 32 di 44
FORMULAZIONE DEI CRITERI DI DIMENSIONAMENTO E
ATTIVITÀ DI COLLAUDO DELLA PIATTAFORMA DI
CALCOLO PARALLELO (HPC)
Hardware della piattaforma HPC
Nell’ambito del progetto è stata collaudata e testata una piattaforma operativa costituita da un
sistema distribuito di nodi, allo scopo di creare un Cluster di tipo Beowulf di High Performance
Computing (HPC), dedicato al calcolo parallelo massivo. L’architettura Beowulf è stata scelta in
quanto è attualmente considerata l’architettura standard per lo sviluppo di soluzioni di clustering
inteso come insieme di computer ad alte prestazioni (in alternativa alle soluzioni HPC proposte dai
Supercomputer). Inoltre è una soluzione ottimale nel caso in esame, in quanto è ideale per eseguire
applicazioni di calcolo parallelo. Inoltre, il rapporto costo/prestazioni di una macchina di tipo
Beowulf è circa tre volte migliore di quello dei tradizionali Supercomputer. Questa architettura è,
infine, facilmente scalabile e permette di semplificare il lavoro di realizzazione e configurazione di
tutto l’ambiente Cluster.
Nell’analisi delle risorse richieste dal progetto, è stato considerato necessario realizzare un ambiente
di testing al fine di poter individuare la configurazione minima richiesta per eseguire la simulazione
e, inoltre, reperire le informazioni necessarie per valutare ed analizzare al meglio il prototipo di
architettura hardware da realizzare. Per tale sistema è stata utilizzata un architettura di tipo Beowulf
di “classe 1” che prevede l’utilizzo di componenti hardware “off the shelf”, ovvero, componenti di
basso prezzo facilmente reperibili in commercio. Dal punto di vista hardware, l’ambiente è
composto da 36 nodi, ciascuno equipaggiato con un processore Dual-core e 2 Gb di memoria Ram
(1 Gb di Ram per core), unità di storage di tipo NAS con hard disk Sata II. Dal punto di vista del
cablaggio, gli Switch di rete per le connessioni Giga-ethernet sono stati collegati tra loro utilizzando
una topologia a stella (non in cascata) con uno switch che funge da master stella per evitare un
eccessivo traffico di rete.
Dopo la realizzazione del sistema, è stato effettuato il monitoraggio dello stesso, a livello fabric
(livello Hardware) per un periodo di una settimana anche con l’ausilio dello strumento di
monitoring open source “Ganglia”. Sono stati analizzati tutti i componenti hardware del sistema:
UPS, tensione delle prese di alimentazione, sistema di dissipazione e ventole, temperature dei
processori e stato della rete e stato di carico delle CPU e delle memorie. Dall’analisi si è verificato
che tutti i componenti funzionano correttamente.
Su questo sistema di testing è stato, quindi, effettuato il benchmark delle prestazioni in modalità
manuale; è stata fatta partire la simulazione e sono stati calcolati i tempi di esecuzione della stessa.
Pagina 33 di 44
Valutando le performance ottenute, sono stati individuati i requisiti minimi richiesti per poter
eseguire la simulazione.
Quest’analisi dei requisiti minimi è fortemente legata al tipo di simulazione che si vuole eseguire e
soprattutto al setup scelto in fase di simulazione. All’interno dell’ambiente di testing è stato
utilizzata una configurazione che prevede 3 domini di elaborazione con opzioni di setting standard.
Tali domini sono stati accuratamente definiti e hanno le seguenti risoluzioni:

Il primo dominio ha risoluzione 9x9 ed è centrato su tutta l’Italia. Questo dominio rappresenta quello
relativo al calcolo delle condizioni a contorno della simulazione.

Il secondo dominio con risoluzione 3x3 è centrato sulla regione Campania. Questo dominio utilizza
le condizioni a contorno ottenute dall’elaborazione del primo dominio e permette di elaborare le
nuove condizioni a contorno del dominio a risoluzione maggiore.

Il terzo dominio con risoluzione 1x1 è centrato su Napoli e rappresenta il dominio di elaborazione
della simulazione.
Per una simulazione standard (eseguendo quindi tutti i moduli previsti), con la configurazione
considerata, sono stati individuati i requisiti minimi per l’elaborazione del software. Tali requisiti
prevedono l’utilizzo di almeno 8 core di calcolo più un nodo Master (head node) per la gestione del
Cluster. Ogni core deve essere composto da:

Un Processore x86_64/AMD64

1 Gb di memoria Ram
Data la quantità limitata di core utilizzati in questa configurazione minimale, è stata giudicata
irrilevante al fine delle prestazioni, la quantità di nodi utilizzati per ottenere il numero di core
individuato come requisito minimo. Quindi, utilizzare 4 nodi di calcolo equipaggiati con processore
Dual-core piuttosto che 2 nodi di calcolo con processore Quad-core non è rilevante.
Su tale infrastruttura, che risponde ai requisiti minimi richiesti, è stato ipotizzato un tempo di
elaborazione della simulazione direttamente scalandolo da quello ottenuto in ambiente di testing.
La durata della simulazione completa, con l’hardware minimo e con il setup descritto sopra, si
dovrebbe attestare intorno alle 12 ore circa di elaborazione (da valutare).
Valutando le informazioni ottenute nell’ambiente di testing, si è quindi valutata la realizzazione di
un prototipo di architettura basato su hardware di ultima generazione quali gli chassis Blade.
Nonostante l’architettura Beowulf preveda l’utilizzo di componenti standard presenti in commercio
al dettaglio, è stato deciso di utilizzare, per questo prototipo, la tecnologia Blade perché, è una
soluzione che permette di ottenere massime prestazioni, altissima scalabilità e minimizzare al
meglio l’occupazione di spazio all’interno della sala server a disposizione. Altra cosa molto
importante, semplifica notevolmente il cablaggio di componenti ingombranti quali cavi di
Pagina 34 di 44
collegamento, alimentazione e connessioni fibre channel. Di fatto all’interno di uno chassis Blade, è
già presente tutto lo spazio per allocare i diversi componenti di rete (compresi i nodi di calcolo).
Inoltre con la tecnologia Blade è possibile ottenere una distribuzione più compatta e organizzata di
tutti i componenti relativi al sistema.
Lo chassis Blade utilizzato è il “Blade Center IBM” sulla quale sono stati montati 4 alimentatori per
ottenere la massima ridondanza del sistema. Per quanto riguarda il sistema di raffreddamento, dato
il numero non eccessivamente elevato di nodi di calcolo, è stata scelta una soluzione classica con
ventole di dissipazione di calore. Lo chassis, inoltre, è stato equipaggiato di 4 switch di rete GigaEthernet per la connessione ridondante tra i nodi di calcolo e 2 switch fibre channel per le
connessioni ad alte prestazioni con il sistema di storage. Per quanto riguarda i nodi di calcolo,
all’interno del Blade Center sono state montate e installate 4 lame Blade di tipo “Blade Server
IBM” di dimensione 2U. Ciascuna lama Blade è stata equipaggiata con 2 processori Quad-core Intel
Xeon 5570, 32 Gb di memoria Ram e 6 schede di rete per ottenere ridondanza nelle connessioni. In
ogni lama Blade sono presenti, quindi, l’equivalente di 8 core di calcolo e 4 Gb di memoria Ram
per ogni core. Come soluzione di storage è stata scelta una soluzione open-storage con connessioni
al alte prestazioni iScsi, in quanto, offre notevoli vantaggi in ambito cluster tra cui alte prestazioni a
prezzi contenuti, facilità di configurazione e software di gestione open source come previsto
dall’architettura Beowulf e infine minimizza l’occupazione di spazio, quindi è complementare alla
tecnologia Blade. Il sistema scelto è il SUN7310 Openstorage iScsi equipaggiato con 11 Terabytes
di memoria Raw.
Dopo aver realizzato il sistema di HPC, è stato effettuato il benchmark di livello fabric utilizzando
il medesimo tool open source “Ganglia”, già utilizzato precedentemente in ambiente di testing. I test
hanno dato esito positivo circa il funzionamento dei componenti.
Infine, è stato calcolato e analizzato il benchmark delle prestazioni con le medesime modalità usate
precedentemente ed hanno evidenziato prestazioni paragonabili a quelle ottenute con l’ambiente
utilizzato nella fase di testing. L’analisi è stata effettuata a parità di setup del software.
Dopo aver realizzato il prototipo della simulazione è stato dimostrato con specifici tool di calcolo
che questa architettura Beowulf basata su tecnologia Blade, scala in maniera quasi proporzionale
con il numero di nodi di calcolo presenti del sistema. Per cui è possibile valutare le prestazioni del
proprio sistema prendendo direttamente a riferimento i dati di benchmark mostrati per questo
prototipo.
Pagina 35 di 44
Software di base
Per quanto riguarda la scelta del sistema operativo dell’infrastruttura di HPC realizzata, dopo aver
valutato le possibili soluzioni, si è quindi scelto di utilizzare un sistema open source basato su
distribuzione GNU/Linux. Questa scelta è dettata da una serie di motivazioni analizzate in fase di
progettazione. Principalmente, le distribuzioni GNU/Linux sono fortemente raccomandate nel caso
di cluster Beowulf. Da un punto di vista economico, le alternative commerciali che integrano in
un'unica soluzione il sistema operativo completo dei pacchetti software integrati nel sistema
necessari per la realizzazione di sistemi HPC, hanno un costo di licenze molto elevato. Un'altra
importante motivazione è che utilizzando le soluzioni commerciali, essendo quest’ultime soluzioni
closed, non si dispone del codice sorgente e, quindi, non sono completamente personalizzabili per le
proprie necessità. Per effettuare modifiche a basso livello (livello kernel) è, quindi, necessario il
supporto del Vendor a cui si rimane necessariamente vincolati.
In particolare, si è scelto di utilizzare la distribuzione Linux denominata Red Hat CentOS versione
5.4.0, opportunamente configurata e ottimizzata per un cluster Beowulf. Questa distribuzione è
performante, ma al tempo stesso estremamente flessibile, scalabile e permette di ottenere incrementi
prestazionali lineari con l’aumento delle unità adibite per elaborazione. Permette di abbattere i costi
di licenza software e ridurre notevolmente i costi di gestione. Infine essendo una soluzione open
source è estremamente personalizzabile e perfettamente adattabile ai nostri scopi.
Sul sistema realizzato per il progetto, quindi, come prima cosa è stato effettuato il download del
sistema operativo Centos versione 5.4 dal sito ufficiale www.centos.org.
Per tutti i nodi dell’infrastruttura (sia Master, sia Slave), per quanto riguarda l’installazione di
Centos , sono state utilizzate le opzioni standard suggerite dall’interfaccia di installazione. Invece,
per la configurazione di base del sistema sono state adottate soluzioni specifiche per l’ambiente di
cluster da realizzare: Configurazione delle variabili di ambiente, configurazione dell’interfaccia di
rete con appropriati indirizzi IP, Gateway e DNS specifici dei singoli nodi del Cluster. Infine è stato
configurato un dominio per la rete.
Al sistema operativo di base, sono stati, inoltre, aggiunti una serie di pacchetti software specifici per
il Cluster, che estendono le funzionalità di base del sistema in maniera tale da consentire e favorire
le operazione tipiche di un cluster. Tali componenti software sono stati opportunamente configurati
in base alle differenti caratteristiche del nodo Master e dei nodi Slave. I pacchetti software per il
nodo Master, a cui è demandato il controllo completo di tutto il cluster, devono essere configurati
per permettere l’accesso dei nodi slave nel sistema cluster tramite login e permettere l’elaborazione
dei task di esecuzione. Tale nodo deve, inoltre, fornire ogni tipo di risorsa ai nodi slave. Ad esso è
demandato anche il ruolo di monitoring del sistema e di punto di collegamento con l’esterno. I nodi
Pagina 36 di 44
slave che sono quelli adibiti al calcolo parallelo, vengono controllati e configurati in modo del tutto
automatico dal nodo Master ed eseguono unicamente le operazione che gli vengono ordinate in
remoto da tale nodo. Devono, quindi, essere in grado di loggarsi nel sistema per essere abilitati
all’elaborazione.
Per quanto riguarda il nodo Master, quest’ultimo deve essere in grado di gestire tutti i servizi
previsti dal Beowulf. Sono stati, quindi, aggiunti una serie di pacchetti software che estendono il
sistema con i servizi fondamentali al corretto funzionamento del nodo:

NFS per la gestione di un File System condiviso

NTP per la sincronizzazione degli orologi di sistema

RPC per permettere la connessione remota tra il Master e gli Slave

NIS Server per l’auto-configurazione l’ambiente di calcolo dei nodi slave e permettergli l’accesso ai
servizi remoti
Su tutti i nodi, quindi, è stato installato un sistema NTP (Network Time Protocol) tramite il tool
"ntp", per poter così ottenere la sincronizzazione degli orologi di sistema tra tutti i nodi del Cluster
tramite la rete.
Al fine di poter ottenere un controllo centralizzato delle autentificazioni degli utenti all’interno
dell’ambiente di elaborazione HPC, sul nodo Master è stato installato un Server NIS (Network
Information Service) che permette proprio di ottenere tale scopo. Tale servizio però per il suo
funzionamento, effettua delle chiamate RPC (Remote procedure call) e necessita quindi, per poter
essere installato ed eseguito, di un sistema di gestione delle chiamate RPC. E’ stato quindi installato
il tool “portmap” che gestisce appunto le connessioni RPC e permette anche di incrementare la
sicurezza del sistema e eseguire procedure in remoto all’interno della rete del Cluster. Una volta
installato il sistema RPC, sempre sul nodo Master è stato quindi installato un NIS Server tramite il
tool "ypserv", è stato configurato un dominio NIS e allo stesso nodo Master è stato impostato il
ruolo di Server NIS per tale dominio.
Infine è stato installato il demone NIS tramite il tool "ypbind" che, una volta avviato, rimane in
ascolto dei Client che devono essere registrati nel dominio NIS (ovvero i nodi Slave).
Per permettere l'accesso remoto sui nodi dell'infrastruttura è stato configurato, su tutti i nodi, una
shell “ssh” e configurato il sistema in maniera tale che, una volta che l'utente si è autenticato nel
sistema tramite inserimento di “user” e “password”, può accedere a qualsiasi nodo del sistema
tramite ssh, senza reinserire la password. Inoltre sono state configurate le home degli utenti in
maniera tale da essere condivise tra tutti i nodi, in questo modo l'utente accede automaticamente al
proprio spazio di disco di cui possiede i permessi (/home/nomeutente) su qualsiasi nodo si
autentifica.
Pagina 37 di 44
Per quanto riguarda il sistema di comunicazione tra i nodi, è stato utilizzato “MPI“ (Message
Passing Interface) come protocollo di comunicazione sia tra i core dello stesso nodo, sia tra i core di
nodi differenti. MPI sono, quindi, anche il set di librerie di programmazione scelte per gli scopi
dell’applicazione per quanto riguarda il calcolo parallelo e distribuito. Tale scelta è stata fatta in
quanto MPI è il protocollo standard de facto per la comunicazione tra nodi all’interno di un cluster
Beowulf, forniscono una buona stabilità operativa, performance elevate e un supporto nativo
dell'elaborazione distribuita. Inoltre, le librerie MPI offrono notevoli vantaggi in termini di
performance rispetto ad altre soluzioni quali ad esempio le PVM (Parallel Virtual Machines),
essendo meglio ottimizzabili per l’architettura Beowulf.
Per quanto riguarda la compilazione di codice MPI, quindi, è stata acquisita la licenza software per
il compilatore MPI ad alte prestazioni della “The Portland Group” specifico per i sistemi Linux.
Tale compilatore è il PGI CDK Accellerator con acceleratore fino a 256 processori, provvisto di
supporto per le schede grafiche GPGPU “CUDA” con licenza floating limitata ad un massimo di 2
utenti. (www.pgroup.com/products/pgicdk.htm).
Per poter monitorare il sistema anche da remoto e poter controllare le prestazioni e l'utilizzo delle
CPU dei nodi di calcolo e le altre risorse di sistema, è stato installato il monitor di sistema open
source "Ganglia" tramite il tool "gmond".
Infine, è stato installato il resource scheduler open source "Torque" che si occupa in maniera del
tutto automatizzata della gestione e schedulazione delle risorse, gestione dei fault dei nodi, gestione
delle code dei processi e scalabilità del sistema.
Il collaudo è stato effettuato eseguendo una serie di test di funzionamento della piattaforma
software. Tutti i test hanno dato esito positivo a conferma del corretto funzionamento delle diverse
componenti applicative.
Pagina 38 di 44
COLLAUDO DELLA PIATTAFORMA HPC - HARDWARE
Superato
 Verifica
collegamenti
e
funzionalità
dell’impianto
elettrico
all’interno della sala macchine.
 Verifica dell’alimentazione ridondata e
controllo voltaggio e
tensione degli alimentatori all’interno dei nodi.
 Verifica funzionamento dei gruppi di continuità (UPS).
 Verifica funzionalità mother board dei nodi di calcolo e nodo master.
 Verifica attività e temperature di picco delle diverse CPU dei singoli
nodi.
 Verifica funzionalità e banda dei bus di comunicazione (FSB, BSB,
ecc) all’interno dei chipset dei nodi.
 Verifica funzionalità delle schede di rete.
 Verifica dei cavi di rete Ethernet e iScsi per la connettività dei nodi e
dello storage con il resto del sistema.
 Verifica integrità dei banchi di memoria RAM del sistema.
 Verifica integrità delle unità di storage secondaria Raw.
 Verifica connettività della storage area network (SAN) tra storage
system e rete del sistema.
 Verifica larghezza di banda delle connessioni ad alte prestazioni
iScsi.
 Verifica del sistema di dissipazione del calore del sistema e corretto
funzionamento delle ventole di raffreddamento
Pagina 39 di 44
COLLAUDO DELLA PIATTAFORMA HPC - SOFTWARE
Superato
 Verifica installazione e configurazione del sistema operativo Centos
per il nodo master e per i nodi di calcolo.
 Verifica configurazione (indirizzi IP, subnet, Gateway, ecc) della rete
di comunicazione tra i nodi del sistema.
 Verifica configurazione del sistema di autentificazione degli utenti
sui nodi (NIS).
 Verifica installazione e funzionalità dell’accesso remoto ai nodi del
sistema attraverso la shell ssh.
 Verifica configurazione della Storage area network (SAN) e
connettività dello storage con il resto del sistema.
 Verifica installazione e configurazione dei pacchetti software per il
nodo master e per i nodi di calcolo.
 Verifica corretta attivazione e esecuzione dei servizi allo start-up dei
nodi del sistema.
 Verifica del monitoraggio effettuato dal software di monitoring
“Ganglia”.
 Benchmark delle prestazioni per analizzare il carico di lavoro delle
CPU dei singoli nodi del sistema.
 Verifica del corretto bilanciamento del carico di lavoro delle CPU
effettuato dal software di gestione delle risorse “Torque”.
Pagina 40 di 44
CONFIGURAZIONE LABORATORIO MOBILE ETLBUS E
DUSTSCAN
Pagina 41 di 44
Pagina 42 di 44
Pagina 43 di 44
ANALISI DEL MATERIALE GRAFICO PRODOTTO
Sono state prodotte mappe relative a 16 scenari con valori di inquinamento non alterati. Ogni
scenario ha una durata media di 5 giorni di simulazione per un totale di 80 giorni simulati e
renderizzati.
Per ogni giorno sono state prodotte mappe a cadenza oraria (24 mappe per giorno) relative a 5
inquinanti selezionati (CO, NO, NO2, O3, PM10). Considerando il numero totale di ore per gli 80
giorni di simulazione, il numero di mappe prodotte è circa 2000 per ogni inquinante selezionato.
Considerando tutti i 5 inquinanti, il numero totale di mappe prodotte è circa 10000.
Per gli stessi scenari ma in versione “PAR 0” (con fattore moltiplicativo quasi 0), sono state
prodotte le stesse quantità di mappe grafiche, quindi ulteriori 10000.
Per quanto riguarda i 3 scenari “PAR 2” (con fattore moltiplicativo pari a 2), sono state prodotte
altre 1800 mappe circa.
Tenendo in considerazione tutte le simulazioni effettuate e le versioni con valori di inquinamento
alterati, il numero totale di mappe grafiche prodotte è di circa 22000.
SELEZIONE DI ALCUNE MAPPE DEGLI SCENARI ELABORATI
Di seguito sono riportate in stampa una selezione di mappe relative al periodo autunnale, invernale
e semi-primaverile relative all’anno 2010-2011.
Pagina 44 di 44

Relazione Finale con Allegati

Transcript

Documenti analoghi

Viterbo, 24 novembre 2016 ore 14:00 – 17:30 Aula Magna

Presentazione STRESS TEST AZIENDALE

n°205 del periodico "BAGNO oggi e domani " IL DESIGN DEL

il dinosauro della fantasia - FESTIVAL DELLA LETTERATURA

Atto Accademico SIMI 2013

LEZIONI DI DESIGN, MERCATO, E SOCIETA` Design dei Sistemi

Definire i livelli essenziali delle prestazioni di assistenza