\documentclass[dutch]{deltares_manual}
%\documentclass{report}
\usepackage{natbib}								% voor referenties
\usepackage[most]{tcolorbox}
\usepackage{ragged2e}
\usepackage{imakeidx}
\usepackage{upquote}% getting the right grave ` (and not ‘)!
\usepackage{setspace}
\usepackage{xfrac}
%\usepackage{fancyvrb}
\newcommand{\bs}{$\backslash$}
\newcommand{\verbatimfont}[1]{\renewcommand{\verbatim@font}{\ttfamily#1}}
\usepackage{listings}
\lstset{ %
	language=C++,           % choose the language of the code
	numbers=none,           % where to put the line-numbers
	numberstyle=\tiny,      % the size of the fonts that are used for the line-numbers
	basicstyle=\tiny    % the size of the fonts that are used for the line-numbers
}

%\usepackage{subfig}
\sloppy
%\FlushLeft
\title{Grevelingen klimaat \mbox{robuustheid}}
\subtitle{Beschrijving van script V5.0 voor optimalisatie van het doorlaatmiddel}
\manualtype{User Manual}
\version{1.1}

%\indexsetup{level=\section,toclevel=chapter,noclearpage, firstpagestyle = empty}
%\makeindex[name=explain, options = -s test.ist, title = Definities, columns=1]
%\makeindex[name=model, options = -s test.ist, title = Model parameters,  columns=1]

\usepackage{glossaries}
\makeglossaries     
\newglossaryentry{hypso}{name = hypsometrische curve, description = {Een beschrijving van het wateroppervlak als functie van de waterstand van de Grevelingen}}
\newglossaryentry{Peilseizoen}{name = peilseizoen, description = {Keuze voor een winter of zomer scenario (obsolete)}}
\newglossaryentry{Scheefstandcor}{name = scheefstandcor, description = {True/False, indien true wordt een tijdreeks van de correctie voor de waterstand in het westen en oosten gebruikt voor de berekening van de debieten door het doorlaatmiddel en sluizen}}
\newglossaryentry{opp}{name = opp, description = {Het wateroppervlakte van de Grevelingen die wordt gebruikt als de hypsometrische curve niet wordt toegepast}}
\newglossaryentry{Peilscenarios}{name = peilscenarios, description = {Definitie van het beoogde peilbeheer voor een periode (over het algemeen meer dan een jaar) en bestaat uit een combinatie van diverse peildefinities}}
\newglossaryentry{Doorlaatmiddel}{name = doorlaatmiddel, description = {Het doorlaatmiddel (al dan niet met turbines) in de Brouwersdam}}
\newglossaryentry{Koker}{name  = opening, description = {Onderdeel van het doorlaatmiddel, te weten een opening waar al dan niet een turbine in is aangebracht. Het doorlaatmiddel bevat 1 of meerdere van dergelijke openingen of kokers}}
\newglossaryentry{Streefpeil}{name = streefpeil, description = {Het minimum of maximum waterpeil dat wordt nagestreefd in de Grevelingen}}
\newglossaryentry{Optimalisatie}{name = optimalisatie, description = {Hier wordt bedoeld het optimaal aansturen van het aantal kokers of turbines om het minimum en maximum streefpeil precies te bereiken en zo een zo kort mogelijke periode te hebben waarin geen water in of wordt uitgelaten. Wanneer er geen doorlaatmiddel is dan kunnen de 5openingen van de Flakkeese Spuisluis worden geoptimaliseerd op dezelfde manier}}
\newglossaryentry{Model run}{name  = model run, description = {Het uitvoeren van het script voor 1 input (*.ini) file. Een dergelijke run kan bestaan uit meerdere simulaties voor 1 of meer zeespiegelstijgingen}}
\newglossaryentry{Scenario}{name = scenario, description = {Een serie van runs voor specifiek peilscenario's en kan bestaan uit simulaties voor meerdere zeespiegelstijgingen (in de \file{*.ini} invoerfile gedefinieerde) en een variatie van het aantal ingezette kokers. Een scenario levert levert de uitvoer om de regenbooggrafieken te genereren}}
\newglossaryentry{Peildefinitie}{name = peildefinitie, description = {Een code (tekst) die gekoppeld is aan een periode waarvoor een minimum en maximum waterstand is gedefinieerd}}
\newglossaryentry{Variant}{name = variant, description = {Definitie van situatie met bijbehorend Peilbeheer, zoals omschreven door “Getij Grevelingen” – Taskforce TM in het document: Nota definitie peilbeheerscenario's, van 24 februari 2022}}
\newglossaryentry{Regenbooggrafiek}{name = regenbooggrafiek, description = {Grafiek die een variabele, zoals waterstand of gegenereerde energie, weergeeft als functie van het aantal kokers (horizontale as) en zeespiegelstijging (verticale as)}}
\newglossaryentry{ZZS}{name = ZZS, description = {Zeespiegelstijging in de Noordzee ten opzichte van 1995}}

\def\labelitemi{$\bullet$}

\begin{document}
\nomenclature[A]{$WL$}{m NAP}{Waterstand in de Grevelingen}
\nomenclature[G]{$\delta t$}{min}{Tijdstap waarnemingen}
\nomenclature[A]{$WLB $}{m NAP}{Waterstand Brouwersehavengat 8}
\nomenclature[A]{$N_{t}$}{-}{Totaal aantal openingen, met en/of zonder turbines in het doorlaatmiddel}
\nomenclature[A]{$S$}{min}{Schuif open(1) of dicht(0)}
\nomenclature[A]{$H_{t}$}{m}{Waterstandsverschil Grevelingen en Noordzee}
\nomenclature[A]{$T_{f}$}{-}{Turbine reactiegraad}
\nomenclature[A]{$C_{l}$}{-}{Verlies coëfficiënt}
\nomenclature[A]{$Q_{sluis}$}{m$^{3}$/s}{Debiet door een sluis}
\nomenclature[A]{$Q_{k}$}{m$^{3}$/s}{Debiet door een opening}
\nomenclature[A]{$optsluit$}{True/False}{True: het sluitcriterium wordt gehanteerd, False: sluitingscriterium wordt niet gehanteerd}
\nomenclature[A]{$sluitdiff$}{m}{Het maximale verhang waarop het doorlaatmiddel mag sluiten}
\nomenclature[A]{$flushwe$}{True/False}{True: Bij de Fakkeese Spiusluis wordt alleen gespuid, geen water ingenomen voor doorspoeloptie}
\nomenclature[A]{$vrijstromend$}{True/False}{True: Doorlaatmiddel bestaat uit vrijstromende openingen in tegenstelling tot verdronken openingen (False)}
\nomenclature[A]{$H_d$}{m NAP}{Ligging van de drempel van een vrijstromend doorlaatmiddel tov NAP}
\nomenclature[A]{$f_{c}$}{-}{Afvoercoefficient} 
\nomenclature[A]{$A_{s}$}{m$^{2}$}{Doorstromend oppervlak van een sluis}
\nomenclature[A]{$Q_{gate}$}{m$^{3}$/s}{totale debiet door de turbines}
\nomenclature[A]{$A_{G}$}{-}{Oppervlak van de Grevelingen}
\nomenclature[A]{$G_{p}$}{W}{Gegenereerde vermogen}
\nomenclature[G]{$\rho_w$}{kg/m$^3$}{Dichtheid van water}
\nomenclature[G]{$\delta_{h}$}{m}{Waterstandsverschil binnen en buiten de sluis}
\nomenclature[G]{$\Phi$}{m$^{3}$/s}{Gepompte debiet}
\nomenclature[A]{$R_{p}$}{-}{Reactiegraad van de pomp}
\nomenclature[A]{$H_{sys}$}{m}{Waterstandsverschil}
\nomenclature[A]{$P_{E}$}{W}{Pompcapaciteit}
\nomenclature[A]{$P_{kin}$}{Wh}{Binnenkomende kinetische energie door de openingen}
\nomenclature[G]{$\eta$}{cP $=$ mPa$\cdot$s}{Viscositeit van water}
\nomenclature[A]{$BF$}{-}{Switch voor Brouwerssluis en Flakkeese spuisluis (altijd open (0) of open/sluiten (1) mee als doorlaatmiddel). Wanneer BF=2 dan is de Flakkeese
spuisluis niet operationeel, dus alleen de Brouwersluis functioneert}
\nomenclature[A]{$Fbsluis$}{-}{Afvoerco\"{e}fficient sluis Brouwersdam}
\nomenclature[A]{$Obsluis$}{m$^2$}{Doorstromend oppervlak sluis Brouwersdam}
\nomenclature[A]{$Ffsluis$}{-}{Afvoerco\"{e}fficient Flakkeese spuisluis}
\nomenclature[A]{$Ofsluis$}{-}{Doorstromend oppervlak Flakkeese spuisluis}
\nomenclature[A]{$Uvoor$}{-}{Tijd in uren voor bepalen hoog of laag water, dus hierin moet in de Noordzee een hoog of laag water vallen}
\nomenclature[A]{$MaxTPower$}{W}{Maximum vermogen die een turbine kan leveren}
\nomenclature[A]{$TurbEff$}{-}{Efficientie van leverend vermogen}
\nomenclature[A]{$SLR$}{m}{Zeespiegelstijging ten opzichte van het referentiejaar (2008) zoals in het model toegepast}
\nomenclature[A]{$Heff$}{-}{Pompefficiëntie (0-1)}
\nomenclature[A]{$Cflow$}{-}{Afvoercoëfficient voor de turbines, deze wordt gebruikt voor de openingen waar turbines in zijn opgenomen}
\nomenclature[A]{$Apomp$}{m$^2$}{Dwarsdoorsnede oppervlak van een turbine}
\nomenclature[A]{$NtFSS$}{-}{Het aantal openingen in de Flakkeese spuisluis (6), als er geen doorlaatmiddel is dan wordt de FSS gebruikt om te optimaliseren}
\nomenclature[A]{$Ntk$}{-}{Aantal openingen zonder turbines in het doorlaatmiddel}
\nomenclature[A]{$Maxlev$}{m NAP}{De beoogde maximum waterstand in de Grevelingen. Deze wordt overschreven  voor de periodes die door het peilscenario wordt gedekt}
\nomenclature[A]{$Minlev$}{m NAP}{De beoogde minimum waterstand in de Grevelingen. Deze wordt overschreven  voor de periodes die door het peilscenario wordt gedekt}
\nomenclature[A]{$Closs$}{-}{verliescoëfficiënt van de openingen}
\nomenclature[A]{$Tff$}{-}{Reactiegraad van de turbine tijdens vloed}
\nomenclature[A]{$Tfe$}{-}{Reactiegraad van de turbine tijdens eb}
\nomenclature[A]{$OptKok$}{-}{Optie voor het type optimalisatie:\newline
	0 : geen \gls{Optimalisatie}\newline
	-1 : met \gls{Koker} \gls{Optimalisatie}:Optimalisatie van aantal openingen (alleen bij instromend water)\newline
	1 : met \gls{Koker} \gls{Optimalisatie}: Optimalisatie van het gebruik aantal openingen (eb en vloed)\newline
	2 : met \gls{Optimalisatie} reactiegraad alleen vloed\newline
	3 : met \gls{Optimalisatie} reactiegraad vloed en eb\newline
	4 : met \gls{Optimalisatie} voor puls (versnelde vloed)inlaat\newline
	5 : met \gls{Optimalisatie} pompen: Pompen (Q uit) en reactiegraad (Q in) \newline
	6 : met \gls{Optimalisatie} voor de hoeveelheid inkomende impuls per getij (kin. energie)
}
\nomenclature[A]{$MaxlevW$}{m NAP}{Maximum waterstand voor de winter periode (wordt niet gebruikt maar nog wel in invoer opgenomen)}
\nomenclature[A]{$MinLevW$}{m NAP}{Minimum waterstand voor de winter periode (wordt niet gebruikt maar nog wel in invoer opgenomen)}
\nomenclature[A]{$Hypso$}{-}{Model input option voor het al dan niet gebruiken van de hypsometrische curve in het model}
\nomenclature[G]{$\Delta t$}{s}{Tijdstap van het model, bepaald door de tijdstap van de aansturende data}
\nomenclature[A]{$A_{eff}$}{m$^2$}{Effectief oppervlak, deze is gelijk aan $\frac{1}{C_{l}} \cdot A_{DM}$}
\nomenclature[A]{$A_{DM}$}{m$^2$}{Fysiek doorstroom oppervlak van een opening in het doorlaatmiddel}

\setboolean{@twoside}{false}

\hyphenchar\font=-1%
\deltarestitle
\sloppy
%------------------------------------------------------------------------------
\chapter{Het 0D hydraulisch rekenmodel van de Grevelingen}

\section{Inleiding}
Het model zoals dat is geimplementeerd is een 0D model van het Grevelingen, inclusief de openingen Brouwerssluis en het beoogde \gls{Doorlaatmiddel} in het westen en de Flakeesse spuisluis in het oosten. Een globaal overzicht van de Grevelingen is in Figuur \ref{fig:grevelingen}.
\begin{figure}[H]
	\begin{subfigure}[b]{1.0\textwidth}
		%		\sbox0{\includegraphics{figuren/stroomschema.png}}%
		%		\includegraphics[trim = 0 {0.0\wd0} 0 0, clip, width=\textwidth]{figuren/stroomschema.png}
		\includegraphics[trim = 0 {0.0\wd0} 0 0, clip, width=\textwidth]{figuren/grevelingen.png}
	\end{subfigure}
	\caption{Overzicht van de Grevelingen}
	\label{fig:grevelingen}
\end{figure}

Het model berekent debieten door deze openingen leidt vervolgens de waterstand in de Grevelingen af. Het model wordt gedreven door tijdreeksen van de waterstanden van de Krammer (oost) en de Noordzee (west). Verdamping, regenval en kleinere instromingen worden hierbij niet meegenomen. 

%\svnrev

\section{Debieten door het \gls{Doorlaatmiddel} al dan niet met turbines}

Het \gls{Doorlaatmiddel} bestaat uit een aantal \gls{Koker}en. De relaties voor het berekenen van de debieten door de \gls{Koker}en zijn direct uit het spreadsheet van gehaald van Jacob van Berkel (symbolen komen niet pers\'{e} overeen met de oorspronkelijke documenten, \citet{berkel2018}, \citet{berkel2019a}, \citet{berkel2019b}):

\begin{equation}
WL(t) =  WL(t-\delta t) + \frac{100\cdot N_{t}\cdot s Q_{gate}\cdot \delta t}{A_{G}}
\end{equation}
waarbij:
\begin{equation}
Q_{gate} = \frac{(1-S)\cdot 64\cdot \sqrt{2\cdot 9.81\cdot ABS(H_{t}\cdot (1-T_{f})}}{C_{l}}\cdot SGN
\end{equation}
Met:
\begin{itemize}
	\item $ WL $  = Waterlevel Grevelingen
	\item $ WLB $ = Waterlevel Brouwersehavengat 8 (wordt gebruikt als randvoorwaarde)
	\item $ \delta t$ = tijdstap van de data. meestal 10 minuten
	\item $ N_{t}$ = aantal turbines in het doorlaatmiddel
	\item $Q_{gate}$ = totale debiet door de turbines
	\item $A_{G}$ = Oppervlak van de Grevelingen
	\item $S$ = boolean (1/0) dat aangeeft of schuif open op dicht is (dus true/false). Sluit als waterstand in Grevelingen $WLB > G_{max,c}$ en $WLB < G_{min,c}$
	\item $H_{t}$ = Head in m, waterstandsverschil binnen (Grevelingen) en buiten (Noordzee)
	\item $T_{f}$ = Turbine reactiegraad (in de laatste spreadsheet bij eb is deze 0, is een parameter)
	\item $C_{l}$ = Verlies coëfficiënt (in het door J. van Berkel geleverde spreadsheet heet het Conduit loss coefficient)
\end{itemize}
$SGN$ levert het teken aan voor het debiet naar binnen (+) en naar buiten (-) afhankelijk van het waterstandsverschil (buiten min binnen). Het oppervlak van een opening is in deze vergelijking als een vaste waarde opgenomen (64m$^2$). Er wordt ook vaak gewerkt met een afvoercoëfficiënt en die is $A_{eff} = \frac{1}{C_{l}}$.

In het script zijn ook de debieten van de Brouwerssluis en de Flakkeese spuisluis ingebracht. De vergelijkingen voor de beide sluizen zien er in het algemeen vergelijkbaar uit met die van het \gls{Doorlaatmiddel}. 
Die vergelijking voor die twee debieten zijn het doorstromende oppervlak en afvoercoëfficiënt als parameters in de invoer opgenomen. De vergelijking voor de sluizen is dan:
\begin{equation}
Q_{sluis}  = f_{c}\cdot A_{s}\cdot \sqrt{2\cdot 9.81\cdot ABS(H_{t})}\cdot SGN
\end{equation}

Er is dus een directe relatie tussen de afvoercoëfficiënt en de verliescoëfficiënt/reactiegraad:
\begin{equation}
f_c = \frac{\sqrt{(1-T_{f})}}{C_l}
\end{equation}
Wanneer er turbines in het \gls{Doorlaatmiddel} aanwezig zijn kan er vermogen worden gegenereerd. De berekening van het vermogen heeft geen effect op de berekende debieten en vormt een post-processing stap. De vergelijking voor het vermogen is:
\begin{equation}
G_{p} = Te * \rho_w  * 9.81 * Tf * \delta_{h} * Q_{gate}
\end{equation}
waarbij $\delta_{h}$ het waterstandsverschil (binnen/buiten) in m is, $\rho_w$ is de dichtheid van water, $Te$ is de efficiëntie van de turbine en $G_p$ het geleverde vermogen (W). Voor uitvoerverwerking wordt het vermogen omgezet in MW.

Uit dit model komt dus een tijdreeks van de debieten en de waterstand in de Grevelingen en hieruit volgt de gemiddelde en maximale waterstanden die nodig zijn voor het beheer van de openingen.

Er kan ook worden gewerkt met het effedtieve oppervlak van het doorlaatmiddel, ie het oppervlak vermenigvuldigd met de afvoercoëfficiënt. Dit betekent dat een oppervlak van het doorlaatmiddel van bijvoorbeeld 100m$^2$ en een afvoercoëfficiënt van 0.9 leidt tot een effectief oppervlak van 90 m$^2$.

Het doorlaatmiddel kan verdronken (met kokers) zijn, zoals hierboven beschreven, maar ook vrijstromend. De basisvergelijking van het debiet is hetzelfde, echter het oppervlak van het doorlaatmiddel varieert met de waterstand. Het (effectieve) oppervlak is nog steeds de invoerparameter, maar de drempelwaarde (H$_d$)  bepaald de breedte van de opening. Het gegeven oppervlak is dan gedefinieerd bij NAP 0m. De breedte is dan:
\begin{equation}
B_d = \frac{A_k}{-H_d} 
\end{equation}
Het min teken is hier bedoeld om de drempelwaarde een positief getal te laten zijn omdat de drempel zelf beneden NAP 0m moet liggen. Het oppervlak per tijdstap varieert waarbij de breedte dus vastligt en de hoogte bepaald wordt door het gemiddelde van de waterstand buiten (ie Noordzee) en binnen (Grevelingen).

Verder is in de code de optie meegenomen om een koker/opening uit bedrijf te halen voor een maand vanwege onderhoud. Dit staat hard in de code en het is in de huidige versie verondersteld dat dit de maand oktober is. De variabele in de code heet MaintenanceMonth, nu gezet op 10, maar dit kan elke geheel getal zijn van 1 tot en met 12.

\section{Berekening van inkomende hoeveelheid kinetische energie}
De zuurstofconcentratie in de Grevelingen, met name bij de bodem, is een belangrijke indicator dat wordt weergegeven als areaal zuurstofloosheid. Een van de doelstellingen is om het areaal zo klein mogelijk te krijgen. Menging in de Grevelingen speelt hierbij een belangrijke rol. Die menging wordt door diverse factoren bepaald. De wind is een van die factoren, maar ook is van belang de impuls die binnenkomt tijdens instroming (vanuit het doorlaatmiddel). De impuls wordt in deze studie weergegeven als de hoeveelheid kinetische energie en dit is toegevoegd als een uitvoervariabele. De kinetische energie wordt berekend door:
\begin{equation}
	P_{kin}= \sfrac{1}{2}\cdot \rho_{w}\cdot Q_{k}\cdot \left( \frac{Q_{k}}{A_{opening}\cdot N_{tk}} \right)^{2}\cdot \Delta t
\end{equation}
Dit is op dit moment uitgedrukt in Ws, maar in het model wordt het uiteindelijk als Wh/j uitgerekend. Wat voor de menging als een belangrijke indicator wordt gezien is de hoeveelheid kinetische energie die per getij binnenkomt, maar omdat dit voor het jaar 2008 altijd hetzelfde aantal is, is ook de totale binnenkomende hoeveelheid kinetische energie representatief. 

\section{Implementatie van pompen}
Voor de uitwerking van de pompen wordt gebruik gemaakt van een document dat is opgesteld door Jacob van Berkel (\citet{berkel2018})
Er zijn twee manieren van pompen:
\begin{itemize}
	\item verhang ondersteunend (onder invloed van zwaartekracht)
	\item normaal pompen
\end{itemize}

In de debiet vergelijking 
\begin{equation}\label{pomp1}
\Phi = N_t \cdot A_{p}\cdot C_{l} \sqrt{1+R_{p}}\sqrt{2\cdot g\cdot H_{sys}}
\end{equation}
staat een reactiegraad R die iteratief wordt berekent middels:
\begin{equation}\label{pomp2}
R_{p}\cdot \sqrt{1+R_{p}}=\frac{P_{E}\cdot \eta}{C\cdot \rho \cdot g\cdot A \sqrt{2 \cdot g \cdot H^{3}_{sys}}}
\end{equation}
De reactiegraad van de pomp wordt iteratief door een intrinsieke functie opgelost. De bovenstaande uitwerking is voor pompen tegen het verhang in. Dit wordt beschouwd als normaal pompen. Het is echter ook mogelijk om te pompen als ondersteuning bij het spuien. Dit betekent dat er wordt gepompt met het verhang mee. In de pompvergelijkingen \ref{pomp1} en \ref{pomp2} wordt $1+R_{p}$ vervangen door $R_{p}-1$. Dat betekent dus:

\begin{equation}\label{phi}
\Phi = N\cdot A_{p}\cdot C \sqrt{R_{p}-1}\sqrt{2\cdot g\cdot H_{sys}}
\end{equation}
De reactiegraad R die iteratief wordt berekent door:
\begin{equation}\label{Rp}
R_{p}\cdot \sqrt{R_{p}-1}=\frac{P_{E}\cdot \eta}{C\cdot \rho \cdot g\cdot A \sqrt{2 \cdot g \cdot H^{3}_{sys}}}
\end{equation}

De pompen hebben ook een maximale capaciteit dat is gespecificeerd via de $P_E$. In eerste instantie is die waarde gelijk aan de maximale opbrengst van de turbine, maar tijdens de studie wordt ook gekeken naar de verlaging van de getijslag door de maximale pompcapaciteit te beperken. Dit wordt in het script als een aparte parameter gezien vanaf Versie 3.1 van het model.

\section{Modelaansturing}
Het model wordt aangedreven door waterstandstijdreeksen (2008 en 2009) die door RWS zijn geleverd voor: 
\begin{itemize}
	\item Brouwerhavensegat 08
	\item Krammersluizen West
\end{itemize}

Deze tijdreeksen geven de waterstand elke 10 minuten. Dit is dan gebruikt als rekentijdstap in het model. De huidige versie 5 is geschikt voor een tijdreeks voor beide randvoorwaarden van 2010 tot en met 2018. Deze data wordt na de eerste simulatie als pycle file opgeslagen (ivm performance). Er kan voor worden gekozen om het model voor een deel van deze periode te draaien, maar deze specificatie loopt per jaar, dus alleen gehele jaren. 

Het oppervlak van de Grevelingen is in het model als een parameter weergegeven, maar er is door RWS een tabel beschikbaar gemaakt waarbij het wateroppervlak is weergegeven als functie van de waterstand (\gls{hypso}) Het relevante deel van die tabel (Bijlage \ref{appA:hyspomet}) laat zien dat het oppervlak tussen hoog en laag water (NAP-45 tot 5 cm) in de Grevelingen zo'n 10\% kan variëren.
Met deze variatie van het wateroppervlak als functie van de waterstand wordt in het model rekening gehouden. Dit heeft invloed op het berekenen van de nieuwe waterstand als er een hoeveelheid water is ingelaten. 

\chapter{Uitwerking in python}
\section{Het \gls{Optimalisatie}proces in het python script}
In het script wordt een \gls{Optimalisatie} uitgevoerd op het gebruik van het aantal \gls{Koker}en per getijslag om een zo optimaal mogelijk getij in het Grevelingen te genereren.  
Dit betekent dat bij iedere getijslag wordt berekend hoeveel \gls{Koker}en open moeten staan om precies het \gls{Streefpeil} (dat kan het minimum of maximum waterstand in de Grevelingen zijn) te bereiken en zo de tijdsduur dat er geen water wordt in- of uitgelaten wordt geminimaliseerd. In de huidige toepassing wordt van waargenomen tijdreeksen gebruik gemaakt, maar de predictive control van de \gls{Koker}en kan in dit proces worden toegepast met voorspelde waterstanden als sturende randvoorwaarden. 

Het \gls{Optimalisatie}proces is schematisch in Figuur \ref{fig:optkok} weergegeven.
\begin{figure}[H]
	\centering
	\sbox0{\includegraphics{figuren/optimalisatie_proces.png}}%
	\includegraphics[trim = 0 {0\wd0} 0 {0\wd0}, clip, width=0.8\textwidth]{figuren/optimalisatie_proces.png}
	%	\includegraphics[width=0.5\textwidth]{reportfigs/trk-test5hdisp_t2.png}
	\caption{Schematisch van het optimaliseren van het aantal \gls{Koker}en per getijslag met een optimum van 13 \gls{Koker}en}
	\label{fig:optkok}
\end{figure}

Er zijn meerder \gls{Optimalisatie} mogelijkheden ontwikkeld:
\begin{itemize}
	\item het optimaliseren van het aantal geopende \gls{Koker}en per getij (eb en vloed)
	\item het optimaliseren van het aantal geopende \gls{Koker}en alleen tijdens de vloed
	\item het optimaliseren van de reactiegraad van de turbines alleen tijdens de vloed
	\item het optimaliseren van de reactiegraad van de turbines tijdens de eb en vloed
	\item het zo goed mogelijk gebruiken van de versnelde vloed
	\item het optimaal gebruikt van pompen tijdens eb (bij zeespiegelstijging) voor het handhaven van het peilbeheer
\end{itemize}
Het optimalisatie proces wordt gestuurd door de waarde van $OptKok$ in de invoerfile (file{*.ini}).

\subsection{Het optimaliseren van de het aantal geopende \gls{Koker}en}
Het \gls{Optimalisatie} proces loopt per getijslag (laag naar hoog water of hoog naar laag water) en bepaalt hoeveel \gls{Koker}en er nodig zijn om zo precies mogelijk het limiet peil in de Grevelingen te bereiken. 
Dit wordt bepaald door te beginnen met 1 \gls{Koker} de getijcurve in de Grevelingen te berekenen vanuit de conditie waarmee de vorige getijslag is geëindigd (tot de maximale waterstand). 
Zolang dit maximum onder de limiet is wordt vervolgens naar 2 \gls{Koker}en, 3 etc. gegaan. 
Wanneer de berekende maximale waterstand op of net hoger is dan de limiet, is dat het aantal \gls{Koker}en dat wordt gebruikt voor de simulatie. 
Het zelfde proces wordt ook gebruikt om het aantal \gls{Koker}en te bepalen voor de situatie van hoog naar laag water. 

Er is een mogelijkheid om de \gls{Optimalisatie} uit te voeren voor eb en vloed, maar ook voor alleen tijdens de vloed. Tijdens de eb staan dan alle beschikbare \gls{Koker}en open. Deze \gls{Koker}en sluiten dan allemaal op het moment dat er geen water meer gespuid kan worden (waterstand Noordzee komt boven die van de Grevelingen).

Wat nog wel van invloed is op het aantal te openen openingen is het gebruiken van het sluitcriterium. Bij de gewone optimalisatie wordt niet gekeken naar het verhang tussen de Noordzee en de Grevelingen bij het sluiten van de 
openingen. Aan het ontwerp is wel een eis toegevoegd dat de openingen gesloten kunnen worden in normale bedrijfssituatie bij een verhang van 20cm of minder. Alleen in noodgevallen mag dat meer zijn. Vandaar dat dit sluitcriterium is geïmplementeerd. Wel is het zo dat het mogelijk is dat de sluiting niet kan plaatsvinden bij een verhang van minder dan 20cm. In dat geval wordt in de optimalisatie gekeken naar het aantal kokers of openingen waarbij sluiting plaatsvind met het minimale verhang, ook al is dat meer dan 20cm. Dit wordt in de invoer aangegeven met het keyword $optsluit$ en het bijbehorende maximale verhang $sluitdiff$ (in m). Het kan voorkomen dat de openingen wordt gesloten bij een verhang van meer dan 20cm. De frequentie hiervan kan worden gecontroleerd middels een csv bestand *close.csv dat in de directories ./resultsV5 of ./resultsnohypsoV5 wordt geplaatst bij het draaien van de post-processing timeseriecheckV5.py.

\subsection{Het optimaliseren van de reactiegraad van de turbines}
Voor de \gls{Optimalisatie} van de reactiegraad wordt een vergelijkbare procedure gehanteerd die ook voor de \gls{Koker}en wordt gebruikt. Binnen een getijslag wordt een eerste run gedaan met een reactiegraad van 1  (dus zonder een debiet door de turbines) en in stappen van 0.01 terug naar 0. Het optimum wordt bereikt wanneer de maximale waterstand net wordt bereikt aan het eind van de getijslag. 

Ook voor de reactiegraad is de mogelijkheid aanwezig om te kiezen voor \gls{Optimalisatie} voor zowel vloed als eb, maar er kan ook gekozen worden voor alleen \gls{Optimalisatie} tijdens de vloed. Tijdens eb is de reactiegraad van de turbines op 1 gezet en wordt dus geen vermogen geleverd. 

\subsection{Versnelde vloed}

Bij de versnelde vloed is het doel om een zo kort mogelijke periode te gebruiken om het \gls{Streefpeil} voor de hoogste waterstand te bereiken. Dit levert een groter aantal vrijheidsgraden op. De implementatie van de versnelde vloed is op dit moment gericht op het bereiken van het bovenste \gls{Streefpeil} door zo laat mogelijk de \gls{Koker}en te openen. Turbines zijn bij deze optie niet in het \gls{Doorlaatmiddel} opgenomen. In Versie 4.0 is een tweede puls optimalisatie (optie 6) ingebracht dat als doel heeft het maximaliseren van de totale inkomende kinetische energie per getij. In praktijk betekent dat de kokers open gaan rondom hoog water omdat kort openen met een zo groot mogelijk debiet het meeste impuls oplevert voor menging in de Grevelingen. 

De procedure van \gls{Optimalisatie} is vergelijkbaar met de eerdere \gls{Optimalisatie}s. Het referentietijdstip is het moment dat de waterstand in de Noordzee weer is gezakt tot het bovenste \gls{Streefpeil}. Vanuit dit punt wordt het \gls{Doorlaatmiddel} 10 minuten (1 rekentijdstap) eerder opengezet en de waterstand berekend tot dat moment. Wanneer het \gls{Streefpeil} niet wordt gehaald wordt de opening van het \gls{Doorlaatmiddel} weer met 10 minuten vervroegd. Wanneer het waterpeil in de Grevelingen het \gls{Streefpeil} haalt voordat in de Noordzee het waterpeil onder dit \gls{Streefpeil} komt, wordt dit als optimaal gezien. Het effect hiervan is dus dat het doorlaat middel zo laat mogelijk wordt opengezet en het \gls{Streefpeil} net haalt. 

Het verschil tussen optie 4 en optie 6 is dat de indicator niet meer de lengte van opening is (waarbij de alle kokers zo laat mogelijk opengaan om net het streefpeil te kunnen halen) maar gekeken wordt naar het zo groot mogelijk maken van de hoeveelheid kinetische energie dat naar binnen komt. Het proces kijkt vanuit een moment na het uitstromen en vervroeg het openen. In eerste instantie zal het streefpeil niet worden gehaald, maar wanneer dat wel wordt gehaald worden de kokers nog eerder opengezet. De kokers sluiten op het moment dat het streefpeil wordt bereikt. Bij elke iteratie wordt de opening vervroeg met een tijdstap totdat het maximum van de kinetische energie voor dit getij is bereikt. Hiermee wordt dan de simulatie voortgezet tot het volgende getij waarna het proces wordt herhaald. 

\subsection{Gebruik van pompen}
Bij het gebruik van de pompoptie van de turbines wordt extra gebruik gemaakt van pompen om het minimum waterpeil in de Grevelingen te bereiken wanneer dit onder vrij verval niet mee mogelijk is (ten gevolge van zeespiegelstijging). Tijdens het pompen wordt het energiegebruik geminimaliseerd en tijdens de vloed is de reactiegraad de te variëren parameter om net het maximum peil te halen (energieproductie).

\chapter{Het runnen van het model}
\section{Inleiding}
\label{sec:run_inleiding}
Een globaal overzicht van de benodigde invoer, uitvoer en het proces van het draaien van het model is weergegeven in onderstaande Figuur \ref{fig:stroomschema}. Aan de hand van dit figuur wordt de werking, het draaien van het model en de inhoud en format van de benodigde files uitgelegd. 
\begin{figure}[H]
	\begin{subfigure}[b]{1.0\textwidth}
		\includegraphics[trim = 0 {0.0\wd0} 0 0, clip, width=\textwidth]{figuren/flowdiagram-processing.pdf}
	\end{subfigure}
	\caption{Proces en datastromen Versie V5}
	\label{fig:stroomschema}
\end{figure}
Het model bestaat uit python scripts en het draaien van het model vereist Python 3.7. 
Het versie nummer (in dit geval 'V5') wordt gebruikt in de naamgeving van de invoer en uitvoerdata, behalve in de data directory die niet direct met de scenario's of uitvoer hebben te maken. 
Het versie nummer is in de code opgenomen, op dit moment is dat 5.2. Dit betekent dat de in- en uitvoerdirectories naar dat versie nummer moeten verwijzen. Bijvoorbeeld de directory \dir{./resultsfiguresV5} moet dan worden vervangen door de directory \dir{./resultsfiguresV5.2}. Dit geldt voor alle directories waar het versienummer in is opgenomen. 

Bij het draaien van het model is de basislocatie (werkdirectory) de \dir{working directory}, de data directory \dir{data}, input data directory \dir{scenarios\textit{Versie}} en de directory met de resultaten (\file{results\textit{Versie}} en/of \file{results\_nohypso\textit{Versie}}). Voor de verwerking van de model resultaten middels de twee postprocessing scripts zijn de \dir{resultsfigures\textit{Versie}} en \dir{figures\textit{Versie}\_temp} opgezet. De werkdirectory wordt door de scripts opgezet en het is daardoor belangrijk dat de werkdirectory goed is gedefinieerd. Als de scripts worden gedraaid vanuit een programmeer omgeving, zoals PyCharm, dan is het zaak om de werk directory in de setup te definiëren. Als de scripts vanuit de command line worden gedraaid, dan moet dat vanuit de directory gebeuren waaronder de andere directories aanwezig zijn. In een dergelijk geval wordt het rekenscript gedraaid als volgt:

\command{python rekenmodel/rekenmodel\_grV5.py 2010 2014 2018}

Oudere versies hebben niet de mogelijkheid om meerder jaren in een keer te berekenen.

De 2010 slaat in dit geval op de start periode van de aangeleverde tijdreeksen voor de randvoorwaarden. Deze staan expliciet aangegeven in de \file{modelparm.csv}. Dit wordt gebruikt om te bepalen welke datafiles worden gelezen. Het tweede en derde argument geeft de periode aan dat wordt gesimuleerd, in dit geval is dat 2014 tot en met 2018. De data (randvoorwaarden) beslaat een periode van 2010 tot en met 2021. Het is in Versie 5 mogelijk om te kiezen welke jaren worden gerekend. Het doorrekenen van de volledige 9 jaar kost vrij veel rekentijd en  het doorrekenen van een kortere periode minder hetgeen debuggen wat eenvoudiger maakt en ook de simulaties kan inzoomen op bepaalde jaren indien dat nodig is. 

Alle andere directories zijn gedefinieerd ten opzichte van de werkdirectory en dienen in de omgeving beschikbaar te zijn. 

Het modelscript is zo opgezet dat er wordt gezocht zoekt naar een *.ini file in de directory \dir{./scenarios\textit{Versie}}. De naam van de \dir{scenario} directory heeft de toevoeging van het versienummer van het script (die is gecodeerd in het script). De ini file kan met de hand worden opgezet, maar in het algemeen zal het script in een batch vorm worden uitgevoerd en voor het genereren van de benodigde ini files is een methodiek opgezet om dit eenvoudiger te maken en tevens een geschiedenis te hebben van runs die al gedaan zijn. 

Het systeem voor het uiteindelijk genereren van de modelresultaten bestaat uit een aantal stappen:
\begin{enumerate}
	\item \label{lab:a} Het definiëren van de te simuleren \gls{Scenario}s
	\item \label{lab:b} Het voorbereiden van de model input (pre-processing)
	\item \label{lab:c} Het draaien van het model (voor een serie \gls{Scenario}s)
	\item \label{lab:d} Post-processing van de resultaten
	\item \label{lab:e} (Optioneel) Genereren van randvoorwaarden voor het (Delft3D)FLOW model (zodat het Waterkwaliteitsmodel kan worden gedraaid voor dit \gls{Scenario})
\end{enumerate}
Voor stappen \ref{lab:b}, \ref{lab:c} en \ref{lab:d} zijn python scripts opgezet zodat het proces vrijwel automatisch verloopt. Verder zijn een aantal datafiles nodig die volgens een voorgeschreven formaat zijn opgezet. Mocht dit formaat afwijken dan kan de file worden aangepast, maar het is ook mogelijk om het lezen van de data in het script aan te passen naar het formaat. In dit document wordt uitgegaan van het formaat zoals dat op dit moment door het script wordt gelezen.

Op deze punten wordt in de volgende paragrafen nader ingegaan. 

\section{Het voorbereiden van de model \gls{Scenario}'s (\autoref{lab:a} van \autoref{sec:run_inleiding})}

De basis voor de \gls{Model run}s vormt een spreadsheet waarin alle \gls{Peilscenarios} en runs zijn gespecificeerd. Het spreadsheet staat opgeslagen in de \dir{./scenario\textit{Versie}} directory en wordt uitgelezen door een scenarioscript \file{./rekenmodel/runscenarios.py} die de invoer voor het modelscript klaarzet in dezelfde directory. De volgende definities worden verder in de beschrijving van het draaien van het script gehanteerd:
\begin{table}[H]
%	\caption{This a test caption}
	\begin{tabular}{p{5.5em}p{34.0em}}
		$\bullet$ \gls{Model run}: & het uitvoeren van het script voor 1 *.ini file. Een dergelijke run kan bestaan uit meerdere simulaties voor 1 of meer zeespiegelstijgingen (dit is in de \file{*.ini} file gedefinieerd) \\
		$\bullet$ \gls{Scenario}:& dit is een serie van runs voor een specifiek peilscenario en kan simulaties omvatten voor meerdere zeespiegelstijgingen (in de \file{*.ini} invoerfile gedefinieerde) en een variatie van het aantal ingezette \gls{Koker}en.
	\end{tabular} 
	\label{table:definities}
\end{table}
De basis van het opzetten van de runs en \gls{Scenario}s zijn de definities van de \gls{Peilscenarios}. Deze staan voor de invoer in de directory \dir{./scenarios\textit{Versie}} in een csv bestand dat de basis naam \file{peilscenarios} gevolgd door het simulatiejaar (vooor versie 5.0 en hoger is uitgegaan van een tijdreeks vanaf 2010, maar ook een ander jaar kan worden gekozen mits daar voldoende gegevens voor aanwezig zijn.)
Dit betreft runs die nog gedaan moeten worden maar ook eventueel runs die al gedaan zijn en niet opnieuw gedaan hoeven te worden. Het spreadsheet vormt dus ook een catalogus van alle \gls{Model run}s. Bij het script is een voorbeeld opgeslagen:\\ \\
\file{ScenariosGrevelingen\_v5.2.xlsx}\\ \\
De naam van deze file is hard gecodeerd in het script en is ook gerelateerd aan het versie nummer. en als een ander spreadsheet wordt gebruikt zal dit moeten worden aangepast in het script. Het belangrijkste tabbladen voor versie 5.2 zijn dan UitwerkinghypsoV5.2' en 'Uitwerking\_nohypsoV5.2' (de naam van het tabblad staat ook hardgecodeerd in het scenarioscript). Van beide tabbladen wordt door de pre-processor gebruik gemaakt. Er zijn twee tabbladen om onderscheid te maken tussen de scenarios die wel (UitwerkinghypsoV5.2) en die geen (Uitwerking\_nohypsoV5.2) gebruik maken van de hypsometrische curve. Voor het laaste onderzoek met versie v5 wordt alleen gekeken naar de definities die in de tab Uitwerking\textit{versie} (voor de v5.2 versie dus UitwerkingV5.2) staat. Hierin staan alle model parameters en \gls{Scenario}'s van alle runs en vormt uiteindelijk de invoer van het model, nadat een aantal bewerkingen zijn uitgevoerd. De beschrijving van dit spreadsheet en de bijbehorende invoer data is verder uitgewerkt in de volgende hoofdstukken.

De namen van de scenario's zijn vastgelegd in het scenario spreadsheet. Het algemene patroon van de scenarionaam is 
\begin{enumerate}
	\item basis definitie van het scenario, dit is kolom 'AF' gedefinieerd 
	\item een specificatie van type run, dit is een vrij te kiezen getal of letter (kolom AG)
	\item of het sluitcriterium al dan niet wordt toegepast (kolom O), dit is dan een T of F voor true of false
	\item het al dan niet gebruik maken van de hypsometrische curve, als het wel zo is dan volgt een 'NH' anders dan:
	\begin{itemize}
		\item Verdronken of vrijstromend (true of false) van kolom T, bij True gevolgd door de absolute waarde van de drempel (kolom U)
	\end{itemize}
	\item 'K'gevolgd door het aantal kokers. Als dit getal groter is dan 100, dan wordt dit door het script als het totale oppervlak van het doorlaatmiddel gezien. Dit wordt ook in de post-processing 
	en de regenbooggrafieken gebruikt als een van de onafhankelijke variabelen (aantal kokers of (effectief) oppervlak)
\end{enumerate}

In de xlsx file staan meerdere opties die niet allemaal meer gebruikt worden en waardes van de parameters die in de invoer (*.ini) files terecht komen. 

Als voorbeeld is de run \textbf{B2CTTV6K329} de definitie B2C, met als specificatie T, gevolgd door een T voor het sluitcriterium (de waarde daarvan staat in kolom P) en een vrijstromend doorlaatmiddel ("V") met een
drempel van NAP -6m. Dan volgt de K en de specificatie 329 en dat is het totaal effectief oppervlak van het doorlaatmiddel (in kolom S). Dat totale effectieve oppervlak is het gespeficeerde oppervlak ( aantal openingen - Kolom D maal oppervlak per opening, gedeeld door de verliescoefficient C$_l$). Als de C$_l$ 1 is dan wordt het effectief oppervlak gelijk aan het fysieke oppervlak.
\subsection{Peilscenario's}
De invoerfile \file{./scenarios\textit{Versie}/peilscenario2008.csv} (of een ander jaardefinitie) is in beginsel een csv file waarin alle \gls{Peildefinitie}s die nodig zijn voor een peilscenario in zijn opgenomen. Elke regel definieert een peil en periode waar dit peil voor geldt. Voor een specifiek \gls{Scenario} moet de te simuleren periode minimaal 1 van de in het scenario gekozen peildefinities bevatten. Deze file bevat dus alle mogelijke peil definities. De eerste regel van de file is een header met een korte definitie van de inhoud (de eerste regel wordt niet verder gebruikt). Daarna volgt per regel:\\
\begin{itemize}
	\item \gls{Peildefinitie} (tekst)
	\item startdatum en tijd (dd-mm-yyyy hh:mm)
	\item einddatum en tijd (dd-mm-yyyy hh:mm)
	\item maximum waterstand (cm tov NAP)
	\item minimum waterstand (cm tov NAP)
\end{itemize} Een voorbeeld van een regel is:

\begin{Verbatim}
	VIGB,01-01,31-12,-10,-30
\end{Verbatim}

Bij Versie 5 is het jaar niet meer onderdeel van de specificatie omdat de huidige versie voor meerdere jaren kan worden gedraaid en het peilbeheer voor elk jaar van die simulatie hetzelfde is.

Hierbij is \textit{VIGB} de \gls{Peildefinitie}. Deze definitie wordt weer gebruikt in het opzetten van het peilscenario dat in een \gls{Model run} is opgenomen. Hierna volgt de start datum en einddatum . De laatste twee getallen zijn het onderpeil en bovenpeil in cm ten opzichte van NAP.

De definitie moet uniek zijn binnen de gehele file. Het eerste deel van de volledige definitie bestaat uit een code die met RWS is afgestemd (zie Appendix \ref{appA:scenariodef}). Een \gls{Model run} omvat \'{e}\'{e}n of meerdere van deze peilscenario's (verschillende periodes) en een combinatie van de \gls{Peildefinitie}s definieert een peilscenario. De start- en eindtijd van de periodes die in de file zijn gedefinieerd moeten in de simulatieperiode vallen en samenvallen met de rekentijdstippen van de simulatie. Het script levert anders een foutmelding. Het peilscenario dat in een simulatie wordt gehanteerd is gedefinieerd in de \file{*.ini} file. 

\section{Het voorbereiden van de model input (\autoref{lab:b} van \autoref{sec:run_inleiding})}
Het modelscript maakt gebruik van diverse invoergegevens.  Dit zijn:
\begin{itemize}
	\item Waterstand tijdreeksen voor de Brouwersdam doorlaat (en Brouwerssluis) en Flakeesse spuisluis. Deze files zijn opgenomen in de \dir{./data} directory. De waterstanden in deze files zijn uitgedrukt in NAP cm. 
	\item Algemene modelparameters (die normaal gesproken geen onderdeel zijn van het \gls{Scenario}-onderzoek). Deze file is opgenomen in de \dir{./scenario\textit{Versie}} directory.
	\item invoer modelparameters \file{*.ini} (die in het algemeen variëren voor de verschillende \gls{Scenario}s). Deze file is opgenomen in de \dir{./scenario\textit{Versie}} directory.
	\item Hypsometrische data (wateroppervlak als functie van de waterstand in de Grevelingen). Deze file is opgenomen in de \dir{./data} directory.
	\item scheefstand data die het verhang aangeeft in de Grevelingen van west naar oost. Deze file is opgenomen in de \dir{./data} directory.
	\item Peilscenario file. Deze file is opgenomen in de \dir{./scenario\textit{Versie}} directory.
	\item Hoog en laag water informatie van de Noordzee. Deze is voor 2008 en 2009 aanwezig \file{BG8-rij-extremen-2008.dat} en \file{BG8-rij-extremen-2009.dat} en geeft aan wanneer deze zijn opgetreden.
\end{itemize}
\subsection{Algemene modelparameters}
In de parameterfile \file{modelparm.csv} zijn parameters opgenomen die niet gevarieerd worden tijdens het draaien van alle \gls{Scenario}s, een voorbeeld is in Appendix \ref{appA:modelpar} weergegeven. Deze model parameters worden in het algemeen niet gevarieerd tijdens het simuleren van diverse scenario's. Dit betekent ook dat het niet mogelijk is om in dezelfde map meerdere runs op te zetten waarbij bijvoorbeeld verschillende randvoorwaarde files worden gebruikt. 


\section{Het draaien van het model (\autoref{lab:c} van \autoref{sec:run_inleiding})}

\subsection{Invoer modelparameters}
Het modelscript is opgezet om meerder runs in een keer te draaien. Het script zoekt op de ini files (dit is een van de input files) en gebruikt die om de runs te doen. Als in de directory \dir{scenarios\textit{Versie}} *.ini files staan zal het script al deze invoer gebruiken voor de runs. Het genereren van de ini files gaat via het script \file{runscenarios.py}. Dit script maakt direct gebruik van een spreadsheet waarin alle parameters staan die kunnen worden gevarieerd per run en die in de *.ini file worden weggeschreven. Het meest recente spreadsheet met alle gebruikte simulatie opzet is meegeleverd \file{ScenariosGrevelingen\_v20190228V4.xlsx}. 
Het is belangrijk dat de runnaam verder geen letter 'K' bevat om dat de postprocessing hier gebruik van maakt om de zelfde scenario runs (met variërend aantal kokers) bij elkaar te voegen. 

In beginsel loopt het script door alle ini files die in de map aanwezig zijn en alle SLRs die in de modelpar files zijn gespecificeerd. Als dit te veel runs wordt kan dit leiden tot geheugen problemen waardoor een aantal sommen niet volledig of niet draaien, dit dient wel gechekt te worden. Als dat zo is dan kan dit via een batch file worden uitgevoerd, een voorbeeld van een dergelijke batchfile is 
\begin{lstlisting}
echo Preparing ini files for the runs
python p:\11206580-003-waterkwaliteit-grevel\005-0D-modellering\0Dmodel\rekenmodel\runscenariosV5.py
echo run the model each scenaroi separately. 
@ECHO OFF
Echo ====================Scenario run==================================================
cd scenariosV5
rename *.ini *.iniorg
for %%f in (*.iniorg) do (
echo -------------------------------Scenario run: %%~nf ---------------------------
rename %%~nf.iniorg %%~nf.ini
cd ..
python p:\11206580-003-waterkwaliteit-grevel\005-0D-modellering\0Dmodel\rekenmodel\rekenmodel_grV5.py  2010 2010 2018
cd .\scenariosV5
rename %%~nf.ini %%~nf.iniorg
cd ..
echo generate check plots
python p:\11206580-003-waterkwaliteit-grevel\005-0D-modellering\0Dmodel\rekenmodel\timeseriescheckV5.py  2010 7 1 31 %%~nf 2017
cd .\scenariosV5
)
cd ..
echo ==================Generate regenbooggrafieken
python p:\11206580-003-waterkwaliteit-grevel\005-0D-modellering\0Dmodel\rekenmodel\plot_summariesV5.py 2010 2018
\end{lstlisting}

De kolommen '\gls{Scenario}' en '\gls{Peilscenarios}' in het spreadsheet worden afgeleid uit overige invoer. De scenarionaam (kolom \gls{Scenario}) wordt samengesteld uit de definitie van het \gls{Scenario}, of de turbines al dan niet worden ingezet (TA/TU in kolom 'Spec') gevolgd door het aantal \gls{Koker}en. Als er geen gebruik gemaakt wordt van de \gls{hypso} (dit is van belang wanneer de resultaten van berekening ook wordt gebruikt als randvoorwaarden (debieten) van het hydrodynamische model. Dit heeft te maken met waterbalansen in het hydrodynamische model), dan wordt 'NH'toegevoegd aan de \gls{Scenario}naam, voor de specificatie van dhet aantal kokers in de naam. Het Oppervlak dat is gespecificeerd in het spreadsheet wordt dan gebruikt door het modelscript. Als de \gls{hypso} wel wordt gebruikt, wordt deze informatie gehaald uit de hypsometrische data dat in een csv bestand is opgeslagen \file{data/grev\_opp-diepte\_01.txt}.
Het \file{runscenarios.py} script genereert een of meerdere invoerfiles (*.ini). Welke invoerfiles worden aangemaakt hangt af van de keuze in de eerste kolom setup. Wanneer er TRUE is gespecificeerd wordt die rij gebuikt voor een modelrun en dus het aantal TRUE in de kolom bepaalt het aantal ini files dat wordt aangemaakt. Een voorbeeld van een \file{*.ini} file staat in de Appendix \ref{appA:modelpar}. 


\subsection{Binaire opslag van invoer data}
Voor een aantal databestanden wordt door het model script een binaire file gegenereerd, indien deze al niet aanwezig is. Dit is een zogenaamde pycle file, \file{*.pyc}, en de volgende data die hierin wordt opgeslagen zijn:
\begin{itemize}
	\item Waterstand tijdreeksen in de Noordzee en Krammersluizen
	\item Scheefstands data in de Grevelingen
	\item De hypsometrische curve van de Grevelingen
	\item Peildefinities
	\item Tijdstippen van hoog en laag water in de Noordzee
\end{itemize}

Wanneer de informatie verandert dan moet deze file voor het draaien van de simulaties worden verwijderd uit de \dir{data} directory omdat deze file wordt gelezen als deze aanwezig is niet de aangeleverde oorspronkelijke data. Dit is opgezet omdat het lezen van de pycle file aanzienlijk sneller is en noodzakelijk wordt als een groot aantal simulaties wordt uitgevoerd. Er wordt per set randvoorwaarden een pycle file gegenereerd maar ook voor elk peilbeheer. Dat laatste omdat het toegepaste peilbeheer moet worden omgezet in tijdreeksen en voor langere periodes gaat dat ten koste van de performance. 

\section{Beschrijving en post-processing van de resultaten(\autoref{lab:d} van \autoref{sec:run_inleiding})}
Er zijn twee scripts ontwikkeld voor het postprocessen van de resultaten. Er worden overigens ook grafieken gegenereerd door het modelscript zelf (zie figuur \ref{fig:stroomschema}). In het algemeen zijn deze figuren bedoeld voor een eerste check.  Het eerste script (\file{Plot\_summaries\textit{Versie}.py}) produceert de volgend grafieken (voorbeelden zie Appendix \ref{fig:cpdf_wl}):
\begin{table}[H]
	\begin{tabular}{p{9.5em}p{29.5em}}
		$\bullet$ \file{*getijslag*.png}: &Cumulatieve verdeling van de waterstand in de Grevelingen. Ook voor de winter en zomer periode zoals ze in het script zijn gedefinieerd worden gemaakt, alleen deze zijn niet gevalideerd en moeten nog worden gechecked of ze inderdaad voor de goede periode worden afgeleid (zie \ref{appA:peildef})  \\
		$\bullet$ \file{*wlg.png}: &Tijdreeks voor de gehele gesimuleerde period van de waterstand in de Grevelingen, bedoeld om een oogopslag te hebben van het peilbeheer en hoe in het algemeen de peilen worden bereikt \\
		$\bullet$ \file{*summary.png}: & Deze figuur laat de gemiddelde waterstand en getijslag (in de Grevelingen) zien als functie van de Zeespiegelstijging. Ook worden curvers weergegeven van winter en broedseizoen maar deze laatste twee zijn niet gevalideerd en moeten nog worden gecheckt.
	\end{tabular} \\
	\label{table:figtypesmain}
\end{table}
Het belangrijkste resultaat van het model en de post-processing bestaat uit \gls{Regenbooggrafiek}en dat laat zien wat de variatie is voor een range in het aantal openingen van het \gls{Doorlaatmiddel} en zeespiegelstijgingen.

Het tweede script \file{timeseriescheck.py} levert grafieken van tijdreeksen die door het model worden gegenereerd. Het script haalt de resultaten uit de uitvoerfile \file{*debieten*.csv} en voor elke run wordt voor een geselecteerde periode (die hard in het script is gedefinieerd) waarin de waterstanden van de Noordzee en de berekende waterstand in de Grevelingen staat. Verder is ook in de figuur opgenomen de reactiegraad tijdens vloed, de reactiegraad tijdens eb, het totale debiet van de drie inlaten, het relatief gegenereerd vermogen en het relatief benodigde pompvermogen, indien relevant. De figuur is met name bedoeld om te kunnen controleren of het optimalisatie proces doet wat verwacht wordt.

\section{Genereren van randvoorwaarden voor het (Delft3D)FLOW model}
Het model script genereert ook debiet tijdreeksen voor de drie openingen en deze zijn bedoeld om direct te gebruiken als randvoorwaarden in een 2/3D hydrodynamisch model van de Grevelingen wanneer dit model is opgezet met debieten als randvoorwaarden. Voor een dergelijk model is de waterbalans belangrijk. 

%\include{old-documentation}

\chapter*{Bibliography}
\bibstyle{apalike}
\bibliography{0Dmodellibrary}
\include{report_appendix}
%\endgroup%
%\chapter{Glossary}
%\printindex[explain]
%\printindex[model]
%\printindex[symbols]
\printglossaries
%------------------------------------------------------------------------------
\end{document}
