All’interno di INOPIA
Perchè INOPIA
La carenza d’acqua può essere definita come la condizione, limitata nello spazio e nel tempo, caratterizzata da un’insufficiente disponibilità di risorsa idrica rispetto della domanda ad essa connessa. Secondo la definizione di Paulo e Pereira (2006) e Pereira et al (2019): “Water shortage is also a man-induced but temporary water imbalance including groundwater and surface water over-exploitation […]”. («La carenza d’acqua è anche uno squilibrio idrico indotto dall’uomo ma temporaneo, che riguarda lo sfruttamento eccessivo sia delle acque superficiali che delle acque sotterranee […].) Questo concetto è quindi applicabile ai sistemi idrici, che sono l’insieme delle infrastrutture che captano ed eventualmente immagazzinano l’acqua di una o più risorse (superficiali e sotterranee) e la distribuiscono a diverse tipologie di utenze (per uso potabile, irriguo, industriale, ecc.) La condizione di carenza idrica diventa particolarmente grave quando si verificano situazioni di siccità per periodi di tempo più o meno prolungati. È quindi evidente che l’identificazione di indicatori di pre-allarme di condizioni di carenza idrica, che si traduce nell’incapacità di un sistema di soddisfare il fabbisogno idrico delle utenze connesse, deve necessariamente considerare sia la variabilità metereologica (che include gli andamenti climatici di medio-lungo periodo) che le specifiche caratteristiche infrastrutturali e gestionali di ogni sistema idrico. I sistemi di approvvigionamento idrico possono essere estremamente diversificati sia in termini di utenze finali (impianti per acqua potabile, irrigazione, industriali o uso multiplo) sia in termini di risorse utilizzate (bacini naturali e artificiali, acque superficiali, acquiferi alluvionali, sorgenti e impianti di depurazione). INOPIA si propone quindi come uno strumento flessibile di supporto alle decisioni basato sul calcolo del bilancio di massa mensile (volumi d’acqua) di un sistema idrico multi risorsa-multi utenza costituito da elementi che rappresentano le risorse idriche, le utenze, le connessioni e nodi di gestione. Considerando le serie temporali di precipitazioni, le osservazioni di portata disponibile, i fabbisogni di ogni macro utenza, le caratteristiche delle risorse superficiali e sotterranee e le modalità di gestione del sistema idrico e il livello di interconnessione, il tool stima il bilancio idrico individuando il rischio di deficit che insiste su ciascuna utenza/risorsa o sull’intero sistema. L’analisi della relazione storica tra il regime delle precipitazioni, la disponibilità di risorse e i deficit ricostruiti consentono la calibrazione di un sistema di supporto di preallarme di possibili crisi idriche nonché di scenari combinati gestionali, infrastrutturali e climatici.
Elementi Risorse & Utenze
Afflussi (Inflows)
Cosa viene rappresentato
L’elemento INFLOW simula il deflusso superficiale da un bacino di alimentazione che drenai corsi d’acqua e le precipitazioni verso un punto comune come l’afflusso ad un invaso o la portata di un fiume in una determinata sezione.
L’elemento INFLOW fornirà serie temporali di portata media mensile (m 3/s) al WSS (sistema di approvvigionamento idrico).
Gli elementi INFLOW possono essere collegati agli elementi USER (UTENTE), RESERVOIR (INVASO) e MANAGEMENT (nodo di GESTIONE).
Modello integrato
L’elemento INFLOW ha un modello integrato in INOPIA, chiamato SPI-Q, che riproduce la portata media mensile basata sulle anomalie delle precipitazioni. E” un modello afflussi-deflussi di tipo multiregressivo basato sull’indice di precipitazione standard (SPI)(Romano et al. 2017; Romano et al. 2018), considerando un’ipotesi di stazionarietà nella relazione tra anomalie di precipitazione a diverse scale temporali e la risposta idrologica del bacino per un determinato mese dell’anno.
Quando si aggiunge un elemento INFLOW al sistema idrico (WSS), all’utente è richiesto di fornire un file delle precipitazioni, con una o più serie cumulate a scala mensile (mm) e un file di afflusso con portate osservate.
Le singole serie temporali di precipitazione possono avere valori mancanti, ma è necessario che sia presente almeno un valore per ogni mese della sequenza temporale della simulazione.
Diversamente, la portata osservata può avere valori mancanti, ma dovrebbe avere almeno un valore noto per ogni mese dell’anno. La qualità del modello risultante (sulla portata stimata) dipenderà fortemente dall’entità della serie temporale di portata osservata. A seconda del caso di studio, potrebbero essere necessari da 20 a 30 anni di osservazioni per ottenere una calibrazione adeguata.
Per ogni singola serie temporale di precipitazione, INOPIA stimerà SPI associati a diverse scale temporali (1,3 e 6 mesi) tipici di processi idrologici veloci (es. deflusso superficiale), medi (es. umidità del suolo) e lenti (es. infiltrazione)considerati alla scala di bacino.
Per ogni mese dell’anno viene calibrata una regressione multilinearetra la portata osservata e i valori medi SPI (tra le stazioni disponibile nel file delle precipitazioni) di ciascuna scala:
\(Q(m_i )=a_0 (m)+a_{SPI1} (m) \cdot SPI1(m_i )+a_{SPI3} (m) \cdot SPI3(m_i )+a_{SPI6} (m) \cdot SPI6(m_i )\)
dove \(Q(m_i)\) è la portata per il mese m, anno i
\(SPI1(m_i )\), \(SPI3(m_i )\) e \(SPI6(m_i )\) sono gli Indici di Precipitazione Standardizzati(SPI) per il mese m, anno i basati sulle precipitazioni cumulate a 1, 3 e 6 mesi.
\(a_{SPI1} (m)\), \(a_{SPI3} (m)\) , \(a_{SPI6} (m)\) e \(a_0 (m)\) sono i coefficienti ottenuti dalle multiregressioni sugli SPI1, SPI3, SPI6 per il mese m.
Come risultato, l’elemento INFLOW fornirà al WSS una portata mensile continua sulla base della disponibilità temporale delle serie di precipitazione (esempio: se è disponibile una serie temporale di precipitazione per il periodo 1950-2020 e una serie di portata osservata per il periodo 1990-2015, si avrà come risultato una portata simulata per il periodo 1950-2020).
Lo SPI-Q calibrato sarà quindi disponibile per simulazioni di tipo stocastico, scenario e di previsione.
Template per l’input del dati
Quando si aggiunge un nuovo elemento INFLOW, all’utente è richiesto di fornire un file di precipitazione (con una serie temporale relativa una stazione) e un file di portata (con una serie temporale di portata).
The template input files for precipitation is available at the following link.
The template input files for INFLOW discharge is available at the following link.
Input opzionali
Il file di portata può contenere un foglio opzionale chiamato “External”, con i risultati di una modellazione esterna (in alternativa ai risultati del modello integrato). Il template del file di input per la portata relativa all’elemento INFLOW con il foglio opzionale è disponibile al seguente link link.
Se tale foglio opzionale è presente nel file di portata, all’utente sarà chiesto di scegliere tra modello integrato e modello esterno per l’esecuzione della simulazione di tipo hindcast.
Suggerimento: il foglio “External” può essere utilizzato per eseguire il *run di tipo hindcast con la portata osservata per un periodo senza dati mancanti*
Sorgenti (Springs)
Cosa viene rappresentato
La porzione di precipitazione che si infiltra ricarica la falda e viene esercitata una pressione sull’acqua già presente. Questa pressione sposta l’acqua all’interno della falda e sgorga naturalmente in superficie in luoghi chiamati sorgenti. L’elemento SPRING rappresenta il deflusso naturale superficiale di una falda acquifera in un determinato punto di emergenza (sorgente puntuale).
L’elemento SPRING fornirà al sistema idrico serie temporali della portata media mensile (m 3/s).
Gli elementi SPRINGs possono essere connessi agli elementi USER, RESERVOIR e ai nodi di MANAGEMENT.
Modello integrato
L’elemento SPRING è dotato di un modello integrato (built-in model) in INOPIA, che riproduce la portata media mensile in funzione delle anomalie di precipitazione. E” un modello generico “pioggia-infiltrazione-deflusso” basato su una semplice regressione sullo Standard Precipitation Index (SPI) (Romano et al. 2013; Romano et al. 2017; Romano et al. 2018), considerando un’ipotesi di stazionarietà nella relazione tra anomalia di precipitazione a diverse scale temporali e la risposta idrologica della falda acquifera per un determinato mese dell’anno.
Quando un elemento SPRING viene aggiunto al sistema idrico, all’utente è richiesto di fornire un file di precipitazione con una o più serie temporali cumulate mensili (mm) e un file di portata con portate osservate.
Le singole serie temporali di precipitazione possono avere valori mancanti, ma è necessario che sia presente almeno un valore per ogni mese della sequenza temporale della simulazione.
Diversamente, la portata osservata può avere valori mancanti, ma dovrebbe avere almeno un valore noto per ogni mese dell’anno. La qualità del modello risultante (sulla portata stimata) dipenderà fortemente dalla lunghezza della serie temporale di portata osservata. A seconda del caso di studio, potrebbero essere necessari da 15 a 20 anni di osservazioni per ottenere una calibrazione adeguata.
Per ogni singola serie temporale di precipitazione, INOPIA stima gli SPI associati a diverse scale temporali (da 1 a 24 mesi), eventualmente considerando anche un ritardo (delay) nell’infiltrazione attraverso l’assegnazione di un lag mensile (da 0 a 6 mesi).
Per ogni mese dell’anno viene calibrata una regressione lineare tra la portata osservata e i valori medi degli SPI (tra le stazioni disponibili nel file delle precipitazione) di ciascuna scala e lag:
\(Q(m_i )=a_0 (m)+a_{SPIX_\tau} (m) \cdot SPIX(m_i,\tau)\)
dove \(Q(m_i)\) è la portata per il mese m, anno i
\(SPIX(m_i,\tau)\) è l’indice standardizzato di precipitazione (SPI) per il mese month m, anno i basato sulla precipitazione cumulata a X mesi con delay \(\tau\). Il fattore \(SPIX(m_i,\tau)\) viene selezionato automaticamente da INOPIA in termini di scala e delay sulla base dei risultati migliori ottenuti in termini di correlazione di Pearson con la portata della sorgente.
\(a_{SPIX_\tau} (m)\) e \(a_0 (m)\) sono i coefficienti ottenuti dalla regressione.
Di conseguenza l’elemento SPRING fornirà al sistema idrico valori di portata mensili continui sulla base della disponibilità della sequenza temporale delle precipitazioni (per esempio se si forniscono dati di precipitazione che ricoprono il periodo 1950-2020 e dati di portata osservata che ricoprono il periodo 1990-2015, come risultato si otterrà una portata simulata per il periodo 1950-2020).
Il modello integrato calibrato (hindcast) sarà quindi disponibile per simulazioni stocastiche, scenari e forecast.
Template per l’input del dati
Quando un elemento SPRING viene aggiunto al sistema idrico, all’utente verrà chiesto di fornire un file di precipitazione, con una o più serie temporali cumulate mensili (mm) e un file con una serie temporale di portate medie mensili osservate (m 3/s).
Il template del file di input per le precipitazioni è disponibile al seguente link: link. Il template del file di input per la SPRING è disponibile al seguente link: link.
Input opzionali
«Il file di portata dell’elemento SPRING può contenere un foglio opzionale chiamato “External”, con i risultati di una modellazione esterna (in alternativa ai risultati del modello integrato). Il template del file di input per SPRING con il foglio opzionale è disponibile al seguente link: link.
Se tale foglio opzionale è presente nel file di portata, all’utente sarà chiesto di scegliere tra modello integrato e modello esterno per l’esecuzione della simulazione di tipo hindcast.
Suggerimento: il foglio “External” può essere utilizzato per eseguire il *run di tipo hindcast con la portata osservata per un periodo senza dati mancanti*
Pozzi (Wells)
Cosa viene rappresentato
L’elemento WELLS simula il comportamento di un campo pozzi in termini di volume massimo mensile che può essere estratto dal corpo idrico sotterraneo.
Modello integrato
L’elemento WELL non è basato su un modello integrato che simula il comportamento fisico di un acquifero. Di conseguenza, nessuna variabilità inter-annuale o bilancio di massa interno sono attualmente implementati per l’elemento WELL in INOPIA. Questo aspetto è sia un limite che un vantaggio. Un limite perché lo sfruttamento eccessivo cumulato di un corpo idrico sotterraneo non è esplicitamente monitorato da INOPIA. Un vantaggio perché l’elemento WELL non necessita di complesse (e incerte) parametrizzazioni del suolo e delle acque sotterranee che ne limiterebbero l’uso e nessuna decisione a priori è presa sulla base dei criteri da considerare per la stima della portata massima estraibile (es. supporto ai servizi ecosistemici, limiti tecnologici e infrastrutturali, limiti di concessione, intrusione salina legata ad acquiferi costieri, ecc…).
Per l’elemento WELL, una condizione di deficit si verifica quando la somma delle domande indirizzate alla risorsa per un dato mese è maggiore del volume massimo estraibile.
Per supportare l’utente nel monitoraggio di un possibile sovrasfruttamento a lungo termine di un corpo idrico sotterraneo interessato da un elemento WELL, il plot relativo alla sua serie temporale associata propone una media mobile di 12 mesi considerando la somma di una risorsa non sfruttata e il deficit (cioè tasso massimo di pompaggio - domande).
Tale finestra temporale (12 mesi) è stata scelta come la copertura minima dell’intera stagionalità e può essere sotto o sovrastimata a seconda della dinamica effettiva del corpo idrico sotterraneo. Inoltre, se più campi pozzi pompano dallo stesso corpo idrico sotterraneo, questi possono essere aggregati in un unico elemento WELL per mantenere tale considerazione significativa.
Template per l’input del dati
Quando si aggiunge un nuovo elemento WELL, all’utente è richiesto di fornire un file WELL con il valore del volume massimo mensile estraibile
Il template del file di input per l’elemento WELL è disponibile al seguente link: link.
Invasi (Reservoirs)
Cosa viene rappresentato
L’elemento RESERVOIR simula una capacità di accumulo superficiale, memorizzando l’evoluzione nel tempo dei volumi immagazzinati in un invaso, naturale o artificiale, alla scala mensile. Esso è basato sul bilancio di massa (volumi) calcolato considerando come dati di input l’afflusso definito da uno o più elementi INFLOW o SPRING connessi, la capacità di immagazzinamento, definita da un volume massimo e da un volume morto, e la domanda complessiva indirizzata all’elemento, relativa al mese corrente.
Modello integrato
L’elemento RESERVOIR calcola il bilancio di massa per il mese t nel RESERVOIR in accordo con i seguenti dati di input: il volume invasato alla fine del mese precedente \(V(t -1)\); l’afflusso totale all’invaso relativo al mese corrente \(Q_{IN}(t)\); i volumi effettivamente distribuiti dall’elemento RESERVOIR a tutti gli elementi USER connessi \(SUP(t)\);
Il bilancio di massa dell’invaso è calcolato come segue:
\(V(t,)= V(t -1) + \Sigma_j Q_{IN}(t,j)- \Sigma_u SUP(t,u)\)
dove la somma su u è estesa a tutti gli elementi USER (compreso il deflusso ecologico) connessi con l’elemento RESERVOIR e la somma su j a tutti gli elementi INFLOW o SPRING connessi con l’elemento RESERVOIR
:math:`V(t -1)` of the first month of simulation is taken from initial volume supplied in the RESERVOIR input file.
Template per l’input del dati
Quando si aggiunge un nuovo elemento RESERVOIR, all’utente verrà chiesto di fornire il volume massimo, il volume morto e quello iniziale
Il template del file di input per l’elemento RESERVOIR è disponibile al seguente link: link.
Input opzionali
Il file di input dell’elemento RESERVOIR può contenere due fogli opzionali chiamati Level e hypsographic.
Il template del file di input per l’elemento RESERVOIR con i fogli opzionali è disponibile al seguente link: link
Il foglio Level contiene le serie temporali del volume osservato dell’invaso e verrà utilizzato(se disponibile) durante il plot delle serie temporali, fornendo un set indipendente di dati di validazione per la simulazione hindcast. Il foglio hypsographic contiene i dati della curva ipsografica (altitudine sul livello del mare (m (s.l.m.)) e volume corrispondente (Mm 3)), consentendo la definizione di livello di allarme per il tool di *early warning * applicato all’invaso.
Risorse idriche alternative (Alternative Water Sources (AWS)
Cosa viene rappresentato
L’elemento AWS consente di implementare risorse non convenzionali caratterizzate da un tasso massimo di sfruttamento che può essere fornito per un determinato mese. Alcuni esempi di risorse alternative sono: impianti di desalinizzazione, impianti di depurazione, raccolta di precipitazioni o captazione di acqua dolce sottomarina.
Modello integrato
L’elemento AWS considera il tasso di sfruttamento massimo mensile e nessuna variabilità inter-annuale è attualmente implementata per questo elemento di INOPIA.
Per l’elemento AWS, si verifica una condizione di deficit quando la somma delle domande indirizzate alla risorsa per un determinato mese è maggiore del volume massimo sfruttabile.
Template per l’input del dati
Quando si aggiunge un nuovo elemento AWS, all’utente viene chiesto di fornire un file AWS con il tasso di sfruttamento massimo mensile utilizzabile
Il template del file di input per l’elemento AWS è disponibile al seguente link: link.
Domanda (USER)
Cosa viene rappresentato
L’elemento USER rappresenta una domanda idrica mensile, che può essere per uso potabile, irriguo o industriale.
Modello integrato
L’elemento USER non è attualmente basato su un modello integrato che consideri la variabilità inter-annuale delle domande mensili (es. fabbisogno irriguo sulla base dell’umidità del suolo o fabbisogno potabile basato sulla popolazione).
Ciascun elemento USER è caratterizzato da:
1.Il fabbisogno idrico mensile
2.Il livello di priorità assegnato dall’utente durante la procedura di inserimento dell’elemento USER
La priorità assegnata (un numero intero compreso tra 1 e 10) è in relazione a quella di altri elementi USER eventualmente connessi ad una o più risorse condivise. Ad esempio, se due USER con priorità 1 e 2 rispettivamente sono collegati alla stessa risorsa, lo USER con priorità 1 sarà soddisfatto in via prioritaria.
Ulteriori informazioni riguardo le regole di connessione possono essere reperite in Topology & connections rules
Per l’elemento USER, si verifica una condizione di deficit quando la domanda idrica per un dato mese è maggiore dell’acqua disponibile nella risorsa/e connesse, considerando sia la priorità che le regole di gestione (cfr Management node)
Template per l’input del dati
Il template del file di input per l’elemento USER è disponibile al seguente link: link.
Flusso ecologico (Ecological flow)
Cosa viene rappresentato
Il flusso ecologico è considerato nel contesto del Water Framework Directive (WFD) come «il regime idrologico coerente con il raggiungimento degli obiettivi ambientali della WFD per i corpi d’acqua naturali di superficie[…].»
In INOPIA, l’elemento Ecological flow è considerato come un elemento USER con lmassima priorità.
Modello integrato
L’elemento Ecological flow considera come input la portata mensile erogata e accederà alla risorsa/e connessa/e con priorità assoluta.
Template per l’input del dati
Il template del file di input per l’elemento Ecological flow è disponibile al seguente link: link.
Topologia & regole di connessione
La progettazione di un WSS (Sistema idrico) può rivelarsi un compito complesso a seconda del numero di elementi e connessioni da considerare.
INOPIA intende semplificare questo compito, utilizzando la raccolta di elementi messi a disposizione, adattattabili ad ogni specifico WSS.
Per una ottimale gestione in INOPIA, è consigliabile disaggregare gli schemi complessi in altri più semplici seguendo poche e semplici regole:
connettersi dalle Risorse agli elementi USERs (eccezione: connessione dall’elemento INFLOW a RESERVOIR)
disaggregare lo schema WSS di tipo multirisorsa-multiutenza nell’unione di sotto schemi:
Monorisorsa-multiutenza
Multirisorsa-monoutenza
Lo schema monorisorsa-multiutenza è gestito per priorità. Lo schema multirisorsa-monoutenza prevede l’utilizzo del nodo di GESTIONE (MANAGEMENT node), di seguito descritto, che gestisce l’allocazione di ciascuna domanda (elemento USER) alle risorse connesse.
Le regole sono rappresentate graficamente di seguito:
Monorisorsa-multiutenza
In uno schema idrico monorisorsa-multiutenza, ogni elemento USER è caratterizzato da un fabbisogno idrico, espresso in volume mensile e eventualmente variabile di mese in mese, e dalla definizione di un ordine di priorità impostato dall’utente in relazione agli altri elementi USER.
Nel seguente schema si suppone che l’ordine di priorità sia U1<U2<U3. La priorità è visualizzata con un numero posto accanto a ciascun elemento USER
Il caso monorisorsa-multiutenza non necessita di un nodo di GESTIONE, poiché viene gestito in base alla priorità degli elementi USER connessi. Gli elementi USERs con la stessa priorità condividono il deficit della risorsa connessa. Questo aspetto fa aumentare il tempo di calcolo (a causa del fatto che il deficit da condividere non può essere anticipato a-priori). Quindi nel caso in cui più elementi USERs condividano la stessa priorità e accedano alla stessa risorsa, è consigliabile che siano aggregati in un singolo elemento USER.
Multirisorsa-monoutenza
Nel caso multirisorsa-monoutenza, è necessario inserire un nodo di GESTIONE (MANAGEMENT node) tra gli elementi rappresentanti la risorsa (INFLOW, RESERVOIR, WELLS, AWS) e l’elemento USER.
Nello schema seguente si suppone che un elemento USER possa accedere alle risorsrappresentate dagli elementi RESERVOIR, SPRING e WELLS; nello schema topologico, l’ordine di priorità è rappresentato da un numero posizionato accanto all’elemento USER
Three built-in approach are currently implemented in the INOPIA MANAGEMENT node:
gestione in priorità
L’elemento USER accede alle risorse in priorità (ad es. invia prima la richiesta all’elemento RESERVOIR, se non completamente rifornito all’elemento SPRING ed infinese è necessario all’elemento WELLS)
gestione in allocazione statica
The USER accesses the resources with predefined monthly allocation ratio (e.g. the user address 0.5 (i.e. 50%) of its demand to the RESERVOIR, 0.3 to the SPRING and 0.2 to the WELLS)
gestione in allocazione dinamica
The USER accesses the resources with dynamic monthly allocation proportions, depending on the resource availability. The allocation proportions are then estimated by INOPIA management node at each time step during the run, depending on the relation defined by the user between the resource state and the ratio to be used. Such relation, is setable through a parameterization of a generic logistic function, excepted for the last listed resource which will receive all the eventual unadressed demand.
Tutte queste regole sono modificabili attraverso l’interfaccia utente MANAGEMENT, e ulteriormente descritte in Management node.
Impostare una connessione
Per impostare una connessione, dopo aver selezionato l’icona nella barra degli strumenti, è necessario posizionare il cursore sul primo elemento e premere il tasto sinistro prima sul primo elemento e poi sul secondo, e successivamente premere il tasto destro del mouse per uscire dal tool.
Mappare un Sistema Idrico (WSS) in INOPIA
La mappatura di un WSS in INOPIA è potenzialmente il compito più complesso, e la sua complessità dipende dal livello di interconnessione. L’intenzione di INOPIA è di essere adattabile ad ogni situazione. Per rendere il compito più semplice, di seguito si suggeriscono alcune buone pratiche:
Identify your “MACRO” resources
Se più campi WELLS accedono allo stesso corpo idrico sotterraneo, è consigliabile aggregare la loro portata massima estraibile in un singolo elemento. Se più SPRINGs provengono dallo stesso corpo e si comportano in modo simile (ovvero alta correlazione tra portate medie mensili) è auspicabile valutare l’aggregazione. Se più INFLOWs affluiscono ad un serbatoio comune, è auspicabile valutare l’aggregazione e stimare l’INFLOW complessivo (Qin) per variazioni di livello (DV) e osservazioni di portata dell’invaso (Qout) (Qin(t)=DV+Qout(t)) che includeranno il bilancio tra evaporazione e deflusso superficiale.
Identificare i “MACRO” USERs
Gli elementi USERs che condividono la stessa priorità, risorse e relative regole di accesso possono essere aggregati. Questa operazione semplificherà lo schema, velocizzerà la simulazione e semplificherà l’analisi e l’interpretazione dei risultati.
Dividi il tuo schema in sottoschemi di tipo «monorisorsa-multiutenza» e «multirisorsa-monoutenza»
Come descritto in Topology & connections rules identifica le risorse che soddisfano le multi utenze e l’utenza soddisfatta da risorse multiple.
Contattaci
INOPIA è un progetto open source, sviluppato in una piattaforma GitLab. Ogni potenziale collaboratore è il benvenuto. Il contributo può variare dalla condivisione delle problematiche all’accesso alla piattaforma GitLab come osservatore o come sviluppatore del plugin (Python 3) o della documentazione (Sphinx)
Il nodo di GESTIONE
Cosa viene rappresentato
Il nodo di GESTIONE (MANAGEMENT node) è in grado di stabilire le regole secondo cui un elemento USER può accedere a risorse multiple. Nell’implementazione di un WSS si possno avere più nodi di GESTIONE.
Modello integrato
Three built-in management rules are currently implemented in the INOPIA MANAGEMENT node, priority management, static allocation managment and dynamic allocation management. Each rule impacts differently the demand allocation scheme as well as associated resources supplied water and deficits. A MANAGEMENT user interface will pop-up once a MANAGEMENT node is connected to a USER and more resources, to able the user to choose and parameterize the rule. The interface will always be accessible through editing, and reset if changes occur in the connections (i.e. removed or added connections)
Una volta premuto il pulsante ok verrà applicata la regola di gestione selezionata (e la sua parametrizzazione)
Di seguito sono illustrate le tre regole di gestione basate su sull’esempio di sopra.
gestione in priorità
L’elemento USER accede alle risorse rispettando l’ordine di priorità. L’elenco delle priorità può essere facilmente modificabile con una semplice operazione di click & drag (trascinamento in posizione superiore o inferiore) nel pannello delle risorse collegato.
Nell’esempio, la domanda rappresentata dall’elemento USER è indirizzata prima all’elemento WELLS, in secondo luogo, se non è pienamente soddisfatta, all’elemento RESERVOIR, e infine all’elemento SPRING. Viene inoltre illustrata l’applicazione della regola di priorità per un solo mese, con una domanda (USER) di 10 Mm 3.
una domanda di 10 Mm 3 viene inviata all’elemento WELLS, che è in grado di fornire un volume massimo 2 Mm 3. Rimangono ancora 8 Mm 3 per soddisfare la domanda. L’elemento WELLS registra un deficit potenziale di -8 Mm 3, che rappresenta la risorsa mancante necessaria a soddisfare tutta la domanda ad esso indirizzata. Questo deficit è considerato potenziale poiché non è un effettivo deficit per l’elemento USER né per il sistema idrico (WSS), in quantol’elemento USER indirizzerà la domanda residua alla risorsa successiva in base alla lista di priorità.
remaing 8 Mm 3 demand is sent to the RESERVOIR, for which the current available volume is 5 Mm 3. 3 Mm 3 are still to be supplied to the demand. The RESERVOIR registers a potential deficit of -3 Mm 3, representing the missing resource necessary to supply all the addressed demand. This deficit is considered potential as this is not an actual deficit for the USER neither for the WSS, as the USER will address the remaining demand to the next resource in the priority list.
la restante richiesta di 3 Mm 3 viene indirizzata all’elemento SPRING, la cui portata può fornire 1 Mm 3. SPRING registra un effettivo deficit di -2 Mm 3, che rappresenta la risorsa mancante necessaria per soddisfare interamente la domanda indirizzata. Questo deficit è considerato effettivo per l’elemento USER e per il WSS, poichè l’elemento USER non ha ulteriori risorse disponibili.
L’esempio è limitato ad un singolo elemento USER. In caso di multiutenza, INOPIA cumulerà gli elementi USERs, il deficit di risorse e il deficit potenziale sulla base della topologia implementata, le priorità dell’elemento USER e le regole di gestione.
The potential deficit is defined only for priority rule
gestione in allocazione statica
L’elemento USER accede alle risorse con un rapporto di allocazione mensile predefinito. Il valore proporzionale può essere modificato nell’interfaccia di gestione. La somma del rapporto per un dato mese da essere uguale a 1. I valori proporzionali possono essere gli stessi per tutti i mesi (la casella «Change apply to all months» è in grado di riempire una riga intera in una sola volta) o variare stagionalmente.
Nell’esempio, il rapporto è impostato per tutti i mesi come 0.3 (ovvero 30%) per l’elemento WELLS, 0.5 per RESERVOIR e 0.2 per SPRING. Si illustra inoltre l’applicazione della regola di priorità per un solo mese, con una richiesta dell’elemento USER di 10 Mm 3.
Il 30% dei 10 Mm 3 (ovvero 3 Mm 3) della domanda viene inviato all’elemento WELLS, il cui volume massimo estraibile è di 2 Mm:sup:3. WELLS registra un deficit di -1 Mm 3, che rappresenta la risorsa mancante necessaria per soddisfare tutta la sottodomanda indirizzata. L’elemento USER registra un deficit di -1 Mm 3.
Il 50% dei 10 Mm 3 (ovvero 5 Mm 3) viene inviato al RESERVOIR, il cui volume attuale è superiore alla domanda. L’elemento RESERVOIR fornisce tutti i 5 Mm 3 richiesti e registra un deficit nullo. L’elemento USER mantiene un deficit di -1 Mm 3.
Il 20% dei 10 Mm 3 (ovvero 2 Mm 3) viene inviato all’elemento SPRING, che ha una portata che può fornire 1 Mm 3. L’elemento SPRING registra un deficit effettivo di -1 Mm 3. L’elemento USER registra un ulteriore deficit di -1 Mm 3, quindi un deficit totale di -2 Mm :supp:`3`.
L’esempio è limitato ad un singolo elemento USER. In caso di multiutenza, INOPIA cumulerà gli elementi USERs, il deficit di risorse e il deficit potenziale sulla base della topologia implementata, le priorità dell’elemento USER e le regole di gestione.
gestione in allocazione dinamica
L’elemento USER accede alle risorse con un rapporto di allocazione mensile dinamico, a seconda della disponibilità delle risorse. Il rapporto di allocazione è quindi stimato dal nodo di GESTIONE di INOPIA per ciascun passo temporale durante il run, a seconda della relazione definita dall’utente tra lo stato della risorsa e il tasso da utilizzare. Tale relazione è impostabile tramite una parametrizzazione di una generica funzione logistica, ad eccezione dell’ultima risorsa elencata che riceverà tutta l’eventuale domanda non indirizzata. L’ordine della lista delle risorse può essere modificato con una semplice operazione di click & drag (clic e trascinamento) nel pannello delle risorse connesse. La funzione logistica è stato scelta perchè in grado di riprodurre un processo decisionale sia stepwise (altamente non- lineare) che smooth (quasi lineare). La funzione logistica è definita da sei parametri collegando lo stato della risorsa con il tasso di domanda.
- Quattro parametri definiscono l’intervallo della funzione:
-«min» e «max» sono il valore minimo e massimo valore della risorsa lungo cui la logistica è definita. L’unità da considerare dipende dal tipo di risorsa.
-«Coeffmin» e «Coeffmax» sono i valori minimo e massimo del rapporto.
- Due parametri definiscono la forma della funzione:
-«break» definisce il valore della risorsa in corrispondenza della quale viene presa una decisione (con un rapporto tendente a «coeffmin» se lo stato della risorsa è minore del valore di «break» e un rapporto tendente a «coeffmax» se lo stato della risorsa è superiore al valore «break»)
-«shape» modifies the shape of the resulting logistic function, from a sharp change (toward «coeffmin» and «coeffmax» at «break») to a smooth change, depending on the value, as illustrated in the following example.
Nell’esempio, in primo luogo viene considerato WELLS, in seconda istanza l’elemento RESERVOIR,ed infine la restante domanda è rivolta all’elemento SPRING.
Lo stato della risorsa WELLS (Q disp) per il mese corrente, considerando la parametrizzazione della funzione logistica per il mese considerato, porta a un rapporto di 0.2. Il 20% della richiesta di 10 Mm 3 (ovvero 2 Mm 3) viene inviata a WELLS, il cui massimo volume erogabile è di 2 Mm 3. Gli elementi WELLS e USER registrano un deficit nullo.
Lo stato della risorsa RESERVOIR (V disp) per il mese corrente, considerando la parametrizzazione della funzione logistica per il mese considerato, porta ad un rapporto di 0.5. Il 50% della domanda rimanente degli 8 Mm 3 (i.e. 4 Mm 3)è indirizzata a RESERVOIR, il cui volume attualmente disponibile è 3 Mm 3. Gli elementi RESERVOIR e USER registrano un deficit pari a -1 Mm 3.
La totalità della domanda rimanente (10-2-4)= 4 Mm 3 viene indirizzata all’elemento SPRING, la cui attuale portata può fornire 2 Mm 3. SPRING registra un deficit di -2 Mm 3. USER registra un ulteriore deficit di -2 Mm 3, quindi un deficit totale di -3 Mm :supp:`3`.
Run
Run hindcast
Il run di tipo hindcast è il cervello centrale di INOPIA . Calcola il bilancio di massa mensile del sistema implementato.
Una semplice interfaccia consente all’utente di selezionare la finestra temporale da simulare, di default viene proposta la finestra temporale massima per la quale tutti i dati necessari sono disponibili (considerando anche la scala di SPI calibrata per gli elementi SPRING e INFLOW).
Il run hindcast dovrebbe essere in grado di adattarsi a qualsiasi schema che segua «Topology & connections rules» utilizzando i dati forniti per ciascun elemento connesso tramite i template in formato excel. Il bilancio di massa è calcolato sia a livello di elemento che di approvvigionamento idrico, dal momento che ogni elemento immagazzina il proprio bilancio di massa.
Il run hindcast fornisce un modo diretto per testare il WSS implementato rispetto alle osservazioni, se disponibili. I tools di plot integrati in INOPIA forniscono una valutazione della stima della portata di SPRING e INFLOW così come un confronto visivo con la variazione di livello osservato dell’elemento RESERVOIR, se fornito. I tools di export integrati consentono di effettuare ogni possibile tipo di valutazione di qualsiasi elemento del bilancio di massa, sulla base delle osservazioni disponibili, per adattarsi a qualsiasi esigenza.
Inoltre, il run hindcast può essere facilmente utilizzato per molti altri scopi come
-scenari di gestione aggiungendo/modificando elementi di gestione
-scenari infrastrutturali aggiungendo/modificando elementi relativi a risorse e/o connessioni
-scenari di domanda aggiungendo/modificando elementi di utenza
-scenari climatici fornendo dati riguardo scenari di precipitazione nei template degli elementi INFLOW e SPRING
tutti questi scenari possono essere facilmente combinati, rendendo INOPIA un DDS versatile.
Altre tipologie di run sono state pre-implementate per semplificare l’uso del run hindcast per specifiche domande, tutte basate sullo stesso algoritmo. Il loro utilizzo viene reso disponibile dopo l’esecuzione di un primo run hindcast.
Run stocastico
*»E se avessi 500 anni di dati di bilancio di massa sul mio WSS in esame considerando un clima stazionario per ottenere statistiche migliori?»
Si potrebbe utilizzare INOPIA per fornire statistiche affidabili relative al WSS in esame (per la stima degli indici di siccità integrati e come sistema di supporto alle decisioni per l’allerta precoce o per qualsiasi altra necessità attraverso gli strumenti di esportazione).
Statistiche robuste sugli eventi di deficit di solito richiedono molti più dati rispetto a quelli forniti agli hindcast (tipicamente pochi decenni), come di consueto il WSS e il fabbisogno idrico si adattano reciprocamente per un determinato territorio while precipitation drought are by definition rare on a stationary climate baseline.
Se si volesse fornire ad INOPIA secoli di dati meteorologici generati per rispondere alla domanda «e se avessi 500 anni di dati sul bilancio di massa relativi al WSS in esame considerando un clima stazionario per ottenere statistiche migliori?, allora si può utilizzare il run di tipo stocastico.
L’algoritmo genera una serie temporale di precipitazione di 500 anni che segue il pattern di autocorrelazione calibrato sulla base delle precipitazioni osservate. Una descrizione del generatore meteorologico e della sua implementazione può essere trovato in Romano et al., 2017.
Run Scenario
«Come si comporta il mio sistema di approvvigionamento idrico in scenari di cambiamento climatico? Quali possono essere le strategie di adattamento?»
E” possibile utilizzare INOPIA per supportare l’adattamento ai cambiamenti climatici.
La siccità da precipitazioni è per definizione rara in un clima stazionario. Diversamente, il cambiamento climatico in corso influisce sulla variabilità delle precipitazioni, includendo la stagionalità, la periodicità su larga scala così come le frequenze e l’intensità di anomalie estreme.
«I modelli climatici sono uno degli strumenti principali per gli scienziati per capire come il clima è cambiato nel passato e come potrebbe cambiare nel futuro. Questi modelli simulano la fisica, la chimica e la biologia dell’atmosfera, terra e oceani in grande dettaglio, e richiedono computer molto potenti per generare le loro proiezioni climatiche. I modelli climatici sono in continuo aggiornamento, poichè diversi gruppi di modellazione in tutto il mondo inseriscono risoluzioni spaziali più elevate, nuovi processi fisici e cicli biogeochimici. Questi gruppi di modellazione coordinano i propri aggiornamenti in base alla pianificazione dei rapporti di valutazione dell”Intergovernmental Panel on Climate Change (IPCC) Panel on Climate Change (IPCC)*, rilasciando una serie di risultati relativi al modello." https://www.carbonbrief.org/cmip6-the-next-generation-of-climate-models-explained/
(figura da https://www.ipcc.ch/report/ar6/wg3/downloads/report/IPCC_AR6_WGIII_SPM.pdf)
Utilizzando il run di tipo scenario, è possibile fornire ad INOPIA scenari di modelli climatici utilizzando la parametrizzazione hindcast per rispondere alla domanda Come si comporta il mio sistema di approvvigionamento idrico in scenari di cambiamento climatico? Quali possono essere le strategie di adattamento?.
Sarà necessario fornire uno scenario di precipitazione per ogni elemento INFLOW e SPRING connessi contenenti gli scenari climatici di precipitazioni che si voglionotestare. Poichè il run di tipo scenario utilizzerà la parametrizzazione del run di tipo hindcast,è necessario che gli scenari di precipitazione forniti siano ridimensionati (downscalati) sulle medesime stazioni utilizzate nell”hindcast, in modo tale che i quantili seguano la medesima distribuzione. Tale «trasformazione» può essere ottenuta mediante un semplice «quantile mapping», come presentato in Guyennon et al. (2013).
Poichè esistono molti modelli climatici, scenari di emissione, tecniche di downscaling statisticocostantemente aggiornati, la selezione del modello climatico di precipitazione mensile/scenari/dowscaling dipende dall’utente ed è fornito ad INOPIA attraverso il file template di precipitazione (link )
Il run di tipo scenario può essere combinato con scenari di gestione, infrastruttura e domanda modificando il WSS implementato prima di eseguire lo scenario climatico.
Run Forecast
«Come si comporterà il mio sistema di approvvigionamento idrico nei prossimi mesi ?»
è possibile utilizzare INOPIA per supportare decisioni a breve termine (da uno a sei mesi) sulla base di previsioni stagionali.
Quindi è possibile fornire ad INOPIA scenari di precipitazioni stagionali basati sulla probabilità che si verifichino situazioni umide o asciutte nei prossimi mesi per rispondere alla domanda «Come si comporterà il mio sistema di approvvigionamento idrico nei prossimi mesi ?». Tali scenari possono essere basati sulle ipotesi di modellazione della tendenza climatica stagionale e spesso espressa in termini di anomalie attese (ad es. umido, normale, secco) o sulla classificazione delle anomalie, come ad esempio quella fornita dall’Osservatorio europeo della Siccità (EDO)
(Tabella da https://edo.jrc.ec.europa.eu/documents/factsheets/factsheet_spi.pdf)
Questo significa fornire ad INOPIA i dati dei prossimi 6 mesi di precipitazioni previste per ogni stazione utilizzata per ogni elemento INFLOW e SPRING connessisulla base di uno scenario di anomalia previsto e utilizzare il run forecast. All’utente è richiesto di indicare l’anomalia di precipitazione prevista in termini di Standardized Precipitation Index nel range [- 3, + 3]. Il run di tipo forecast fornirà i relativi scenari di impatto sul sistema di approvvigionamento idrico in esame su orizzonti temporali fino a 6 mesi.
All’utente è richiesto di indicare l’anomalia di precipitazione prevista in termini di Standardized Precipitation Index nel range [- 3, + 3] per il sistema di approvvigionamento idrico implementato ed eseguire una simulazioni per i 6 mesi successivi.
Edit tool
Applicato all’elemento Risorse
Lo strumento EDIT applicato agli elementi Risorse consente all’utente di selezionare nuovi file di input per la risorsa selezionata.
In caso di modifica di un elemento risorsa, ad esempio in questo caso un elemento INFLOW, dopo aver confermato l’inizio della modifica, all’utente sarà chiesto di fornire un nuovo file di precipitazione e uno di portata in accordo con il template corrispondente ( Modello di input)
Il run precedente dovrà essere ricalcolato per tenere conto della modifica.
Tip & tricks : si può utilizzare il tool di modifica sugli elementi INFLOW e SPRING per aggiornare le simulazioni *hindcast (e quindi previsioni) includendo l’ultimo dato mensile disponibile di precipitazione.
Applicato all’elemento Users
Il tool EDIT applicato agli elementi USERS consente all’utente di cambiare il priority level assegnato durante la creazione dell’elemento USER.
Il run precedente dovrà essere ricalcolato per tenere conto della modifica.
Applicato all’elemento Nodo di Gestione
Il tool EDIT applicato al Nodo di Gestione consente all’utente di cambiare la regola di gestione selezionata e la sua parametrizzazione.
Il run precedente dovrà essere ricalcolato per tenere conto della modifica.
Tool integrato di plotting
INOPIA propone 3 tipi di strumenti di plottaggio integrati per supportare l’utente nel valutare il suo WSS.
Una semplice interfaccia consente di selezionare il tipo di run per cui si vuole ottenere l’output grafico.
plot delle serie temporali, applicato a ciascun singolo elemento (ad eccezione del nodo di gestione).
plot dignostico, applicate a ciascun singolo elemento (ad eccezione del nodo di gestione).
plot diagnostico, applicato all’intero WSS (Water Supply System)
Ciascun plot è descritto di seguito.
Plot delle serie temporali
Plot delle serie temporali applicato a ciascun singolo elemento e a ciscun run (ad eccezione del nodo di gestione). dopo aver selezionato l’icona «plot element time series», l’utente clicca sull’elemento da visualizzare e seleziona un run disponibile per generare la figura.
Il pannello superiore delle figure generate riguarda le informazioni di input dell’elemento, indipendentemente dal run selezionato. Il pannello inferiore mostra le variabili mensili di bilancio di massa dell’elemento considerato espresso in Mm :sup:`3`ed il tipo di run. L’utente può selezionare interattivamente le variabili da visualizzare.
Il plot delle serie temporali è illustrato di seguito con due esempi tratti dal tutorial.
Esempio of plot delle serie temporali applicato all’elemento INFLOW, con un run di tipo scenario, tratto dal tutorial
Esempio of plot delle serie temporali applicato all’elemento RESERVOIR, con un run di tipo hindcast, tratto dal tutorial
Tip & tricks: si può applicare anche ad un nuovo elemento senza run disponibile, che può essere utile per monitorare i risultati del modello integrato degli elementi INFLOW e SPRING
Plot diagnostico di un elemento (Element diagnostic) «
Il plot diagnostico di un elemento si applica a ciascun elemento, ad eccezione del nodo di gestione, e a ciascuna tipologia di run. Dopo aver selezionato l’icona «plot element diagnostic», l’utente si posiziona con il cursore sull’elemento da visualizzare, clicca e seleziona un run disponibile per generare la figura.
Il riquadro sinistro della figura è dedicato al valore medio mensile delle variabili di bilancio di massa dell’elemento considerato espresso in Mm 3. L’utente può selezionare interattivamente le variabili da visualizzare, il periodo (nell’ambito del run selezionato) e il mese da considerare.
Il pannello in alto a destra della figura è dedicato al rischio di deficit dell’elemento, in termini di indici di probabilità di accadimento (affidabilità), durata (resilienza) e intensità (vulnerabilità) secondo Romano et al., 2017. Il run stocastico è stato progettato per ottenere una stima più solida degli indici di siccità. L’utente può selezionare interattivamente il periodo (nell’ambito del run selezionato) ed il mese da considerare per le stime degli indici RRV (Reliability, Resiliency, Vulnerability).
Il pannello in basso a destra della figura rappresenta il flusso tra gli elementi, considerando tutti quelli collegati a quello selezionato. L’utente può selezionare interattivamente il flusso da considerare tra acqua allocata, deficit e deficit potenziale, il periodo (nell’ambito del run selezionato) e il mese da considerare per l’elaborazione del Diagramma di Sankey.
Il plot diagnostico di un elemento è illustrato di seguito con due esempi tratti dal tutorial.
Esempio di output grafico ottenuto dal plot diagnostico applicato all’elemento USER con un run di tipo scenario
Esempio di output grafico ottenuto dal plot diagnostico applicato all’elemento WELL con un run di tipo hindcast
Plot diagnostico del WSS
Il plot diagnostico WSS si applica alla totalità di elementi implementati, ad eccezione del nodo di gestione, e a ciascuna tipologia di run. Dopo aver selezionato l’icona «Water Supply System diagnostic», l’utente seleziona un run disponibile
Il pannello di sinistra delle figure è dedicato alla rappresentazione del flusso tra gli elementi del WSS considerando la totalità degli elementi connessi a quello selezionato. L’utente può selezionare interattivamente il tipo di flusso da considerare tra acqua allocata, deficit e deficit potenziale, il periodo (nell’ambito del run selezionato) e il mese da considerare per l’elaborazione del diagramma di Sankey.
Il riquadro in alto a destra mostra il valore medio mensile delle variabili di bilancio del WSS espresse in Mm 3. L’utente può selezionare in modo interattivo le variabili da visualizzare, nonché il periodo (all’interno del run selezionato) e il mese da considerare.
Il pannello in basso a destra della figura è dedicato al rischio di deficit del sistema idrico, in termini di indici di probabilità di accadimento (affidabilità), durata (resilienza) e intensità (vulnerabilità) secondo Romano et al., 2017. Il RUN stocastico è stata progettato per produrre una stima più robusta degli indici di siccità. L’utente può selezionare interattivamente il periodo (all’interno del RUN selezionato) e il mese da considerare per la stima degli indici.
Il plot diagnostico di un elemento è illustrato di seguito con due esempi tratti dal tutorial.
Esempio di plot diagnostico su tutto il sistema idrico (WSS) derivante dal *run hindcast del tutorial con il diagramma di Sankey che evidenzia l’allocazione dell’acqua .*
Esempio di plot diagnostico su tutto il sistema idrico (WSS) applicato al tutorial con il diagramma di Sankey che evidenzia il deficit .
Il tool di Early Warning
Early warning è un tool integrato di INOPIA di supporto alle decisioni Si basa sulla relazione tra le anomalie di precipitazione osservate e il deficit simulato, come proxy della relazione tra la siccità meteorologica e il relativo impatto sulla sicurezza idrica. Si basa sul fatto che, per un dato mese dell’anno, l’occorrenza e l’intensità di un possibile deficit (come misura dell’impatto sulla sicurezza idrica) nei mesi successivi possono essere parzialmente previste in base alle anomalie di precipitazione dei mesi precedenti, sulla base dell’esperienza acquisita. L’approccio e i metodi di allerta precoce sono descritti in dettaglio in Romano et al., 2018.
Il tool di allerta precoce (early warning) si applica allo stesso modo al run di tipo hindcast, stocastico e scenario, ma fornisce risultati più robusti con la simulazione stocastica. Dopo aver selezionato l’elemento, una semplice interfaccia utente consente di scegliere il RUN tra quelli disponibili.
Il tool di allerta precoce (early warning) si applica agli elementi RESERVOIR e SPRING.
Tool di early warning applicato all’elemento RESERVOIR
Dopo aver selezionato l’icona di early warning, l’utente clicca sull’elemento RESERVOIR considerato e seleziona un RUN disponibile per generare la figura.
Nel menu superiore, l’utente seleziona:
il mese di riferimento (quando prendere una decisione). Nell’esempio proposto il mese di riferimento selezionato è Aprile.
la scala di aggregazione dell’SPI (basata sulle precipitazioni dei mesi precedenti a quello di riferimento). Nell’esempio proposto, i mesi di riferimento selezionati sono 6.
la scala di aggregazione del deficit (deficit futuro). Nell’esempio proposto, i mesi di riferimento selezionati sono 5.
Seguendo l’esempio, la richiesta di early warning (allerta precoce) è:
«considerando le anomalie di precipitazione da Novembre ad Aprile (cioè lo SPI6 di aprile) quanto posso prevedere l’occorrenza e l’intensità del prossimo deficit da Maggio a Settembre?».
Il pannello in alto a sinistra mostra la relazione tra il predittore SPI (l’anomalia di precipitazione del mese di riferimento cumulata sulla scala di aggregazione selezionata (aprile SPI6 nell’esempio) e il possibile deficit nei seguenti mesi della scala di aggregazione del deficit (i seguenti 5 mesi, da Maggio a Settembre, nell’esempio). Nell’ipotesi di una relazione abbastanza lineare tra il predittore SPI e il deficit futuro, si può stimare un livello di allarme SPI come il valore in cui la regressione lineare del deficit cumulato non nullo interseca l’asse del predittore SPI. Nel caso in cui l’allarme SPI stimato sia positivo (il che indica una condizione di deficit strutturale dell’elemento RESERVOIR), l’allarme SPI viene impostato a 0.
Inoltre, quando applicata ad una capacità di immagazzinamento, conoscendo lo stato attuale della risorsa può supportare ulteriormente la previsione. Il pannello in alto a destra presenta la relazione tra il volume immagazzinato nel mese di riferimento (Aprile, nell’esempio) e il possibile deficit durante i succesivi mesi della scala di aggregazione del deficit (i successivi 5 mesi, da Maggio a Settembre, nell’esempio). Analogamente all’allarme SPI, l’allarme Volume può essere stimato come il valore del volume in corrispondenza del quale la regressione lineare del deficit cumulato non nullo interseca l’asse del Volume. Nel caso in cui sia presente il foglio di input opzionale ipsografico, l’allarme relativo al volume può essere espresso come allarme di livello in m s.l.m.
I pannelli inferiori della figura sono dedicati alla lezione appresa dalla relazione precedente.
La domanda di early warning con gli associati SPI e volume di allerta stimati sono riassunti a sinistra, e il modello di early warning risultante viene testato: si prevede un deficit se il predittore SPI è inferiore all” SPI di allerta stimato e il volume del mese di riferimento è inferiore al volume di allerta stimato. Ogni mese del run considerato viene quindi classificato in:
Vero Positivo (TP): un deficit è stato previsto e si è effettivamente verificato
Falso Positivo (FP): un deficit è stato previsto ma non si è effettivamente verificato
Vero Negativo (TN): nessun deficit è stato previsto e nessun deficit si è effettivamente verificato
Falso Negativo (FN): non è stato previsto alcun deficit, ma si è effettivamente verificato un deficit
la classificazione è riportata nella matrice di confusione nel pannello in basso a destra.
Infine, le prestazioni del modello di early warning possono essere valutate in termini di:
Il Tasso di Veri Positivi (TPR), definito come il rapporto tra i casi Veri Positivi (TP) e i casi effettivamente positivi (TP+FN): TPR=TP/(TP+FN)
Il Tasso di Falsi Positivi (FPR), definito come il rapporto tra i casi Falsi Positivi (FP) e i casi effettivamente negativi (TN+FP): TPR=FP/(TN+TP)
ambedue (TPR e FPR) sono definiti tra [0-1].
Più il modello di early warning tende verso un Tasso massimo (->1) di Veri Positivi e a un Tasso minimo (->0) di Falsi Positivi, più è robusto. La percentuale dai Veri Positivi e di Falsi Positivi è riportata nel pannello in basso a sinistra.
Di seguito viene illustrato il sistema di ealy warning per la RESERVOIR con due esempi tratti dall’esercitazione.
Esempio di grafico EW applicato al RESERVOIR run hindcast del tutorial.
Esempio di grafico EW applicato al RESERVOIR run stocastico del tutorial.
Il grafico di early warning si aggiorna automaticamente con il variare dei parametri impostati dall’utente. In questo modo è possibile verificare la risposta del RESERVOIR a diverse combinazioni di scale per un determinato mese e identificare la migliore capacità di EW per una determinata configurazione del WSS.
SPRING (sorgente) early warning
Dopo aver selezionato l’icona «early warning», l’utente clicca sulla sorgente (SPRING) considerata e seleziona un run disponibile per generare la figura.
Nel menu superiore, l’utente seleziona:
il mese di riferimento (il mese considerato per l’analisi). Nell’esempio proposto il mese di riferimento selezionato è Luglio
la scala di aggregazione SPI (precipitazioni precedenti al mese considerato). Nell’esempio proposto i mesi di riferimento selezionati sono 9.
il * fattore di ritardo* SPI (ritardo medio di infiltrazione). Nell’esempio proposto i mesi di riferimento selezionati sono 2.
la scala di aggregazione del deficit (deficit futuro). Nell’esempio proposto i mesi di riferimento considerati sono 6.
Seguendo l’esempio, la domanda relativa all”early warning fase di preallarme* è
«prendendo in considerazione le anomalie di precipitazione da Settembre a Maggio (cioè lo SPI9 di Maggio, mese di riferimento) quanto posso prevedere l’occorrenza e l’intensità del deficit nel periodo successivo da Agosto fino a Gennaio?»
Il pannello in alto a sinistra mostra la relazione tra l’SPI predittore (l’anomalia di precipitazione del mese di riferimento, considerando il ritardo, cumulata sulla scala di aggregazione selezionata, che nell’esempio è SPI9 Maggio) e il possibile deficit nei mesi successivi relativamente alla scala di aggregazione del deficit (i successivi 6 mesi, nell’esempio da Agosto a Gennaio). Nell’ipotesi di una relazione sostanzialmente lineare tra l’SPI predittore e il deficit futuro, si può stimare come livello di allarme SPI il valore in cui la regressione lineare del deficit cumulato non nullo interseca l’asse del predittore SPI.
Il pannello in alto a destra presenta la relazione migliore trovata durante la calibrazione del modello integrato dell’elemento SPRING per il mese di riferimento.
I pannelli inferiori della figura sono dedicati alla lezione appresa dalla relazione precedente.
La domanda di preallerta con gli associati SPI e volume di allerta stimati sono riassunti a sinistra, e il modello di preallerta risultante viene testato: si prevede un deficit se il valore predittivo SPI selezionato è inferiore al valore di allerta SPI stimato. Ogni mese del run considerato viene quindi classificato in:
Vero Positivo (TP): un deficit è stato previsto e si è effettivamente verificato
Falso Positivo (FP): un deficit è stato previsto ma non si è effettivamente verificato
Vero Negativo (TN): nessun deficit è stato previsto e nessun deficit si è effettivamente verificato
Falso Negativo (FN): non è stato previsto alcun deficit, ma si è effettivamente verificato un deficit
la classificazione è riportata nella matrice di confusione nel pannello in basso a destra.
Infine, le prestazioni del modello di early warning possono essere valutate in termini di:
Il Tasso di Veri Positivi (TPR), definito come il rapporto tra i casi Veri Positivi (TP) e i casi effettivamente positivi (TP+FN): TPR=TP/(TP+FN)
Il Tasso di Falsi Positivi (FPR), definito come il rapporto tra i casi Falsi Positivi (FP) e i casi effettivamente negativi (TN+FP): TPR=FP/(TN+TP)
ambedue (TPR e FPR) sono definiti tra [0-1].
Più il modello di early warning tende verso un Tasso massimo (->1) di Veri Positivi e a un Tasso minimo (->0) di Falsi Positivi, più è robusto. La percentuale dai Veri Positivi e di Falsi Positivi è riportata nel pannello in basso a sinistra.
L”early warning (allerta precoce) relativo all’elemento SPRING è illustrato di seguito con due esempi tratti dal tutorial.
Esempio di grafico di Early Warning applicato all’elemento SPRING con run di tipo hindcast (dal tutorial).
Esempio di grafico di Early Warning applicato all’elemento SPRING con run di tipo stocastico (dal tutorial).
Il grafico di early warning si aggiorna automaticamente con il variare dei parametri impostati dall’utente. In questo modo è possibile verificare la risposta del RESERVOIR a diverse combinazioni di scale per un determinato mese e identificare la migliore capacità di EW per una determinata configurazione del WSS.
Esportazione
Lo strumento di esportazione consente di esportare in formato xlsx le serie temporali di un singolo elemento, nonché il bilancio di massa dell’intero Sistema Idrico (WSS), per la tipologia di run selezionata. Questo aspetto consente all’utente esperto di realizzare i propri grafici e analisi utilizzando gli stessi dati di INOPIA.
Una semplice interfaccia utente permette di selezionare la tipologia di run (tra quelle disponibili) di cui fare il grafico.
Suggerimenti & trucchi: l’esportazione è disponibile su un singolo elemento anche se non c’è alcuna connessione o se non è stato eseguito alcun alcun run . Questo aspetto consente di utilizzare ed esportare i risultati del modello integrato degli elementi INFLOW e SPRING, nonché i valori SPI calcolati. AAABBBBBCCCCCCCCCDDDDDDD