C a p i t o l o 1
INTRODUZIONE
Il lavoro proposto consiste di due parti principali: la realizzazione di una libreria di lettura per i dati di output del simulatore Relap che si occupa della simulazione degli aspetti termoidraulici di un impianto nucleare e di una libreria di scrittura/lettura dei dati di output del simulatore Dynetz che si occupa di simulare la logica di controllo dei componenti di impianto modellati da Relap.
1.1
Introduzione ai simulatori Relap e Dynetz
Il lavoro di tesi si colloca all’interno di un progetto che mira alla realizzazione di un prototipo, per la Centrale Nucleare Atucha2 (CNAII) in Argentina, in grado di definire una postazione di controllo che, con l’ausilio di interfacce grafiche, fornisca agli utilizzatori la possibilità di visualizzare dati di simulazione, di caricare files di simulazione, di vedere comportamenti dell’impianto in situazioni critiche, il tutto per una visione più immediata degli aspetti di gestione. Tale prototipo considera, al momento, i dati di due simulatori: Relap5, che mostra l’andamento degli aspetti termoidraulici dell’impianto e Dynetz, per il controllo di tali aspetti e l’intervento su di essi per la correzione di diversi parametri in seguito al rilevamento di determinati valori delle grandezze.
Nella gestione di un impianto nucleare, un ruolo fondamentale è svolto da sistemi software che simulano le dinamiche di funzionamento
dell’impianto e consentono lo studio e l’analisi dell’impianto stesso in fase di progetto.
Fig. 1.1 – Schematizzazione semplificata della struttura di un impianto nucleare
Per un utilizzo reale di questi strumenti si rende però necessaria un’organizzazione e gestione efficiente dei dati da essi utilizzati.
Fig. 1.2 – Per ogni aspetto del funzionamento di un impianto esiste un simulatore in grado di gestirlo
Una schematizzazione della struttura di un impianto ad acqua pesante è visibile in Figura 1.1. Le dinamiche di funzionamento sopracitate coinvolgono una molteplicità di aspetti e, per ognuno di essi, esistono dei simulatori in grado di modellarlo, come mostrato in Figura 1.2.
1.2
Descrizione dei simulatori
La gestione di un impianto nucleare comprende anche la gestione di una quantità di dati notevole: infatti ogni aspetto dell’operatività di una centrale, come quello neutronico, termoidraulico, di controllo, di sicurezza, deve essere monitorato costantemente per fornire in ogni momento lo stato dell’impianto con la possibilità di verificarne il corretto funzionamento e di intervenire per modificarlo nelle condizioni che lo rendano necessario.
Questa mole di dati, come nel caso in esame della centrale AtuchaII, funge da input e/o da output, per una molteplicità di sistemi, detti simulatori, ognuno dei quali si occupa di un aspetto del funzionamento complessivo. Pertanto ci sarà un simulatore per l’andamento termico, uno per quello idraulico, uno per quello di controllo, uno per la sicurezza, etc.
Il totale dei simulatori è di circa 20 ed il funzionamento di ognuno di essi in molti casi è legato a quello di altri.
1.2.1 Il simulatore Relap5
Relap5 (da ora in avanti Relap) [5] è stato sviluppato dalla Nuclear
Regulatory Commission (NRC), degli Stati Uniti, per migliorare la stima del
leggera di un reattore durante determinate condizioni di funzionamento, eventualmente anomale o critiche. Il codice modella il comportamento accoppiato del liquido di raffreddamento del reattore e del nucleo in caso, ad esempio, di incidenti con perdita di liquido refrigerante oppure incidenti di reattività; l’approccio è generalizzato in modo da consentire la simulazione di una vasta gamma di sistemi termoidraulici. Infatti il codice comprende molti modelli di componenti generici per la simulazione di un sistema, alcuni dei quali elencati di seguito.
In particolare, Relap è un sistema software per la gestione degli aspetti termoidraulici del funzionamento di un determinato sistema. Utilizza sistemi di controllo multidimensionali per il monitoraggio di aspetti termoidraulici, comprendenti gli scambi termici tra componenti generici e speciali e tutti quegli aspetti che descrivono il comportamento di sistemi complessi fluid-filled [5].
Inoltre, Relap risulta essere internamente interconnesso ed accoppiato con un altro simulatore, chiamato NESTLE, capace di mostrare gli aspetti neutronici del nocciolo in geometria 3D.
I modelli idrodinamici descrivono il flusso di liquidi, vapori e gas non condensabili tra cui aria, idrogeno e azoto. I modelli di trasferimento del calore descrivono la conduzione del calore stesso tra le diverse strutture del sistema ed il trasferimento del calore radiante e connettivo tra le strutture ed i fluidi. I modelli di componenti generici comprendono valvole, separatori, essiccatori, pompe, riscaldatori elettrici, turbine ed accumulatori. I modelli del sistema di controllo includono funzioni aritmetiche, di integrazione e derivazione, logica trip ed altri. I modelli di componenti speciali, sviluppati per l’analisi dei reattori nucleari, comprendono elementi combustibili, modelli della struttura del nucleo e modelli generali per strutture porose.
Relap risulta essere uno dei sistemi di analisi maggiormente utilizzati nel mondo, specialmente nella simulazione di condizioni critiche relative ai livelli di pressione ed alla simulazione di condizioni di guasto e di incidenti. In generale rappresenta un sistema come un insieme di componenti, detti “nodi” (elementi di quella che viene chiamata appunto nodalizzazione di Relap) ed identificati da un codice che ne definisce il tipo. Su ogni nodo, con le proprie caratteristiche fisiche come le dimensioni, l’area, il volume, vengono misurate le diverse grandezze o quantità che forniscono l’andamento nel tempo del sistema, come temperatura, pressione etc.
1.2.2 Il simulatore Dynetz
Il codice Relap permette di modellare la logica di controllo mediante l’impiego di variabili di tipo trip e di tipo control, ma tale tipo di modellazione risulta poco flessibile per sistemi di controllo molto estesi e complessi come quello previsto per CNAII; pertanto si è reso necessario lo sviluppo di un codice per il calcolo dei transitori, chiamato Dynetz e scritto in FORTRAN. Dato che l’alternativa offerta da Relap per la simulazione della logica di controllo risultava inadatta allo scopo, si è proceduto ad utilizzare Relap per definire la nodalizzazione, ossia la struttura del sistema e subroutines Dynetz per l’implementazione del controllo [7].
Dynetz [7] è un software proprietario realizzato da Siemens per il controllo dell’impianto nucleare Atucha. È costituito da una parte termoidraulica e da una parte di logiche di controllo e, nel caso oggetto di studio, si considera la sola componente di controllo.
I componenti definiti dal sistema di nodalizzazione di Relap sono guidati da Dynetz secondo una logica che definisce tre livelli di priorità degli interventi da effettuare per il controllo.
La logica di controllo della centrale è divisa nei seguenti sistemi: Sistema di controllo: fornisce comandi agli attuatori (come valvole, barre di controllo, etc.) che controllano le diverse variabili di processo della centrale.
Sistema di limitazione: fornisce comandi agli attuatori ed ha priorità maggiore del sistema di controllo, intervenendo nei casi in cui le variabili di processo superino limiti prestabiliti; permette inoltre di garantire l’operatività della centrale anche in caso di malfunzionamenti legati al sistema di controllo.
Sistema di protezione: fornisce comandi a priorità massima agli attuatori di controllo e sicurezza; il suo intervento avviene nel caso in cui sia necessario fermare il funzionamento dei processi per garantire un adeguato raffreddamento del reattore.
1.3
Interazione tra i simulatori
Il meccanismo di accoppiamento tra i due simulatori è mostrato, in maniera semplificata, in Figura 1.3. Per un dettaglio dell’accoppiamento tra i simulatori si faccia riferimento alle fasi specificate in seguito.
Fig. 1.3 – Sequenza di interazioni tra i simulatori Relap e Dynetz
Relap si occupa dell’analisi termoidraulica dell’impianto nucleare. Dynetz si occupa invece dei sistemi di controllo (apertura/chiusura di valvole e pompe etc.). Relap non può intervenire in alcun modo su questi sistemi, ma valuterà gli effetti causati dalle variazioni nel sistema di controllo.
Il funzionamento di base è il seguente: Relap inizia l’elaborazione dei dati, comunica i risultati della sua analisi a Dynetz che effettua la propria elaborazione, per poi comunicare ancora a Relap la propria analisi. Questa procedura si ripete fino alla fine dell’esecuzione della simulazione.
Fig. 1.4 – Andamento della simulazione e interazioni tra i simulatori Relap e Dynetz
La Figura 1.4 mostra l’andamento della simulazione. Una freccia di colore rosso indica un passo della simulazione. Per ogni passo si può vedere l’andamento del flusso di informazione tra i due simulatori.
In figura sono utilizzati i seguenti termini per indicare insiemi di variabili dei simulatori:
relvars – Variabili generate e utilizzate solamente da Relap5. ivar – Variabili generate da Dynetz, e sono input per Relap5. ovar – Variabili generate da Relap5, input per Dynetz.
dynvars – Variabili generate e utilizzate solamente da Dynetz. dt – Intervallo di tempo di Dynetz, che viene specificato in un file di configurazione iniziale.
L’interazione avviene in 2 fasi: il passo iniziale ed i passi successivi che seguono tutti la stessa modalità. Ad ogni passo entrambi i simulatori salvano il proprio stato (restart) e lo scambio dei dati avviene mediante file temporanei, sovrascritti di volta in volta.
In fase di inizializzazione in ivarinit è contenuto lo stato iniziale dei
sistemi di controllo. Nei sucessivi passi sarà Dynetz ad aggiornare le condizioni che passerà a Relap tramite le variabili ivart.
E’ importante sapere che è il solo Relap a far avanzare il tempo, mentre Dynetz si limita a fornire informazioni su cosa succederà in un determinato intervallo di tempo (dt, impostato in un file di configurazione).
Segue la descrizione del processo di simulazione. Primo passo:
1) Inizialmente Relap elabora i valori di ivarinit fino al tempo t0, e
genera ovar0 e relvars0.
2) Relap salva lo stato attuale (ovart0, relvarst0, ivarinit) e passa
ovart0 a Dynetz.
3) Dynetz riconosce che è la sua prima chiamata ed elabora ovar0
(ovar0 (t0,dt))
5) Dynetz salva lo stato attuale (ovar0(t0,dt), dynvarst0 e ivart0) e
passa ivart0 a Relap
Secondo passo e successivi:
1) Relap prende lo stato salvato in t0, elabora i valori fino al tempo t1 e genera ovart1 e relvars1
2) Relap salva lo stato attuale e passa ovart1 a Dynetz
3) Dynetz carica dallo stato precedentemente salvato ivart0 e
dynvarst0 ed elabora ovart1(ovar1(t1,dt))
4) Dynetz esegue la procedura Reall2 che genera i valori aggiornati relvars1 e ivar1
5) Dynetz salva lo stato attuale e passa ivar1 a Relap
1.4
Il file di
restart
di Relap ed il file
out
di Dynetz
L’esecuzione di Relap genera dei files detti di restart che risultano essere molto complessi per la quantità di informazioni in essi contenuta.
La parte preponderante del lavoro di tesi è consistita nella realizzazione di una libreria per la lettura da file HDF5 dei dati costituenti il file di restart di Relap, contenente i dati di una simulazione e di un’altra libreria per la scrittura/lettura su/da file HDF5 dei dati di uscita del simulatore Dynetz.
1.4.1 Il file di restart di Relap
Il file di restart di Relap, che rappresenta uno dei file di output del simulatore, contiene lo stato di una simulazione di un transitorio, cioè i dati di funzionamento della centrale in una sequenza temporale secondo
determinate condizioni iniziali. Si tratta di un file binario che, una volta tradotto in formato testuale grazie ad un’applicazione esterna appositamente sviluppata, mostra una struttura come quella riportata in Figura 1.5, ovviamente semplificata ( i numeri ed i colori sono stati inseriti per una migliore comprensione della struttura del file).
Fig. 1.5 – Esempio della struttura di un file di restart di Relap
Tale struttura, tranne le informazioni della prima riga, può essere ripetuta all’interno dello stesso file, in quanto è possibile che una data simulazione venga interrotta in certi istanti per cambiare, ad esempio, la nodalizzazione del sistema e quindi i componenti da simulare, portando a quello che viene detto un restart della simulazione con le nuove condizioni previste.
La struttura base del file consiste in 5 tipi di record (il tipo di record è indicato all’inizio di ogni riga, come mostrato in Figura 1.5):
1) rstplt: identifica il file come file di restart di Relap. Se tale campo non è corretto il file non è un file di restart. Questa riga è formata da:
Nome del programma e numero di revisione ID del file di restart
Data ed ora di scrittura del file Tipo di problema
2) plotinf: specifica il numero di colonne dei campi plotalf, plotnum e plotrec seguenti. Questi due campi seguono sempre un campo plotinf ed esiste un plotinf per ogni restart della simulazione. Inoltre, per ogni restart della simulazione, è presente un solo campo plotinf. Tale campo riporta il numero di elementi, nel primo valore, dei campi plotnum e plotalf seguenti (che hanno uguale dimensione) e nel secondo valore il numero di elementi del campo plotrec.
3) plotalf: contiene la parte alfanumerica dei nomi delle variabili monitorate nella simulazione. Infatti il nome di una variabile è formato da una parte alfanumerica (che solitamente identifica una grandezza, come la pressione ad esempio) e da una parte numerica (un codice che identifica il nodo sul quale è misurata la grandezza). Da ora in avanti un campo contenuto in plotalf sarà detto quantità.
4) plotnum: contiene la parte numerica dei nomi delle variabili simulate. Da ora in avanti un campo contenuto in plotnum sarà detto nodo o punto di misurazione.
5) plotrec: ogni campo plotrec contiene i valori misurati, ad un dato istante di simulazione, per le diverse variabili.
Ad ogni elemento in plotalf sono associati l’elemento di plotnum e quello di plotrec nella stessa posizione, perciò ad ogni quantità (in plotalf) è associato un nodo in cui viene misurata (plotnum) e il valore misurato stesso (plotrec). Tipicamente ad una quantità sono associati molti nodi, perciò si verifica spesso in plotalf la ripetizione di una quantità perché risulta associata, nella riga di plotnum che si trova sotto, ad un codice di nodo differente (Figura 1.6).
Fig. 1.6 – Associazione tra i campi di plotalf e quelli di plotnum. Una quantità è misurata su molti nodi, pertanto sia le quantità in plotalf che i nodi in plotnum risultano spesso
ripetuti.
1.4.2 Il file out di Dynetz
La struttura di un file di output di Dynetz segue quella mostrata in Figura 1.7.
All’inizio del file, la variabile LTMSET = TRUE associata ad un valore del tempo diverso da zero specifica l’offset temporale iniziale della simulazione. La struttura del file non è rigorosa, in quanto il programma sviluppato da Siemens per il simulatore ha subito modifiche da parte degli utilizzatori argentini dell’impianto comportando, tra gli altri effetti, quello di avere un file di uscita con parti in tedesco (ZEIT, tempo) e parti in spagnolo (ad esempio per le note sopra le righe contrassegnate da *, oppure nel caso della parola tiempo). Inoltre la mancanza di rigore ha portato a difficoltà nell’individuazione di regole generali per effettuare un parsing del file per l’individuazione dei dati che sarebbero dovuti essere portati sul file HDF. Pertanto, per tale opera di trasferimento, si è fatto riferimento ad un insieme di regole basate su file reali e casi comuni, non di valenza generale. Infatti, come si vedrà più avanti, i file di output di Dynetz vengono salvati su HDF senza modifiche e l’archiviazione dei dati in essi contenuti in tabelle HDF avviene in una parte separata del documento HDF stesso.
Gli elementi che si ritengono importanti di questo file e che verranno salvati su tabelle separate del file HDF di simulazione sono:
Signal: comprende diversi nomi di subroutines che rientrano nelle categorie illustrate in precedenza, cioè di limitazione, protezione e controllo (ad esempio in figura 1.3 possiamo vedere LGW09 subroutine di limitazione, oppure JR (74) subroutine di protezione).
Status: ogni signal ha associato una stato definito da un valore che può essere T (true) o F (false).
Time: accanto alla parola zeit o tiempo si trova il passo temporale in cui si è verificato l’intervento del simulatore.
Note: nella figura le note sono visibili come frasi, spostate verso destra, nella riga superiore al record che identifica la routine; possono essere anche sulla stessa riga.
