La scelta di procedere a una revisione della codifica del modello è seguita in primo luogo alla necessità di comprenderne a fondo lo schema e il significato delle equazioni.
Tale comprensione era necessaria per procedere allo studio di sensibilità del modello alla variazione dei parametri e per decidere i cambiamenti opportuni alla struttura del modello stesso. La “forma” del modello originale non era soddisfacente sotto molti punti di vista: 1. Il codice del modello non era molto chiaro e non si riusciva a capire il significato di
alcune parti delle equazioni di bilancio (ad esempio dei parametri devo e gravo).
In questo modo non era possibile intervenire sul modello apportando consapevolmente delle modifiche (in quanto non si riusciva a capire cosa si stesse modificando né che cosa ci si poteva aspettare dalle modifiche).
2. Il modello era stato sviluppato in modo da impiegare dei valori prefissati sia per quello che riguardava i parametri operativi e di progetto del DTR (che erano quelli impiegati nelle prove della Tomei con il DTR all’ENEL) sia per quanto atteneva le caratteristiche chimico-fisiche della biomassa utilizzata: tali valori dovevano essere cambiati ogni volta nel codice (che era uno “script” di Matlab del tutto privo di richieste di input all’utente) con il grandissimo rischio di fare confusione, anche per un utente esperto del codice. Inoltre, cambiando il valore di una variabile, non si aveva la garanzia che tale valore fosse cambiato ovunque nel codice: c’erano esempi di variabili definite più volte nel corpo del programma, di valori associati a una variabile che talora erano passati come costanti ecc...
3. Essendo stato concepito per lavorare con un set fissato di valori delle variabili e senza nessuna possibilità di interazione con l’utente, per salvare le informazioni relative a una particolare simulazione occorreva salvare una copia del modello con gli opportuni valori delle variabili cambiati nel codice: per effettuare simulazioni con due tipi di biomasse (carbone Kema e gusci di noccioline) nei casi limite di densità e diametro delle particelle costanti e ad una sola temperatura nominale delle resistenze c’era bisogno di quattro versioni diverse del modello.
4. La quantità e la qualità delle informazioni fornite dal modello nei grafici che risultavano dalle simulazioni mi sono sembrate migliorabili. Inoltre nessuna variabile prodotta nel corso della simulazione veniva salvata in un file. Le uniche informazioni che si potevano trarre dalle simulazioni erano quelle desumibili dai grafici prodotti in output. Gli obbiettivi che mi sono posto nella codifica del nuovo modello, quindi, sono stati:
1. Il testo codificato del modello deve essere di facile interpretazione sia in vista di una sua futura revisione da parte di un utente che deve imparare a conoscerlo, sia per agevolarne il test: ogni parametro (o gruppo di parametri) deve essere definito univocamente nel corpo del programma insieme a tutti i parametri dello stesso tipo (in modo da rendere più semplice la ricerca nel codice del punto in cui un parametro è definito). I parametri, sia variabili che costanti, devono essere opportunamente raggruppati, in base al significato che hanno nelle espressioni del modello: la scrittura delle espressioni del modello risulterà così più compatta e più chiara e il tempo impiegato per ogni step di calcolo sarà inferiore. Tutte le equazioni del modello devono essere scritte in funzione dei gruppi parametrici così definiti (in modo da verificare subito se il risultato della variazione di un parametro è quello atteso in base alle equazioni del modello).
2. Il modello deve garantire un buon grado di interattività con l’utente rispetto alla definizione dei parametri operativi e di progetto: il modello deve consentire di modificare un set abbastanza ampio di tali parametri e disporre comunque di valori di default “ragionevoli” per quei parametri che l’utente non è in grado di fornire.
3. Il modello deve calcolare tutte quelle quantità, variabili al variare della temperatura e delle altre condizioni operative che è possibile calcolare, senza complicare eccessivamente il modello, attraverso relazioni e tecniche reperibili in letteratura o comunque documentate.
4. Il modello deve consentire di salvare quante più informazioni possibili e comunque tutte le informazioni utili ad indagare un qualunque aspetto del fenomeno in esame e desumibili dalle variabili prodotte nel corso della simulazione. Questo non solo per aver sempre disponibili le informazioni tratte da una simulazione ma anche per consentire di ricavare altre informazioni utili successivamente alla simulazione attraverso il “post-processamento” delle variabili.
Il modello attuale consente all’utente di modificare un set di ben 33 parametri, distinti fra parametri del modello, parametri chimico-fisici della biomassa utilizzata, parametri geometrici del rettore e condizioni operative, i più importanti dei quali sono descritti nel seguito (Par. 3.5).
Questo consente un eccellente grado di interattività con l’utente, senza peraltro compromettere la capacità del modello di simulare situazioni in cui tutte queste informazioni non sono note nel dettaglio. Valori di default di tutti i parametri necessari all’esecuzione di una simulazione sono definiti per un set di biomasse diverse. Per il momento questi dati sono salvati nel codice, in una sezione dedicata e con un formalismo semplice e rigido; questo per evitare di doversi portare dietro un file diverso per ogni biomassa. Nulla vieta, nel seguito, di richiamare questi dati da un file.
Inoltre, tutte le informazioni, utili ad indagare un qualunque aspetto del fenomeno in esame, sono salvate periodicamente nel corso della simulazione, in modo che questa possa eventualmente essere ripresa cambiando, ad esempio, la lunghezza del reattore.