Index: dam engine/trunk/doc/Dam Engine - Functional Design/DAM Engine - Functional Design.tex
===================================================================
diff -u -r365 -r369
--- dam engine/trunk/doc/Dam Engine - Functional Design/DAM Engine - Functional Design.tex	(.../DAM Engine - Functional Design.tex)	(revision 365)
+++ dam engine/trunk/doc/Dam Engine - Functional Design/DAM Engine - Functional Design.tex	(.../DAM Engine - Functional Design.tex)	(revision 369)
@@ -1,6 +1,7 @@
 \documentclass[signature]{deltares_report}
 \usepackage[titletoc]{appendix}
 \usepackage{lipsum}
+\usepackage{multirow}
 %-----------------------------------------------
 
 \begin{document}
@@ -41,882 +42,20 @@
 
 \deltarestitle
 
+\include{FO}
+\include{Literature}
 
 %------------------------------------------------------------------------------
-\chapter{Introduction} 
-\label{chapterIntroduction}
+\appendix\chapter*{Appendix} \addcontentsline{toc}{chapter}{Appendix}
+\include{DataCombination}
+\include{REQDataGenerationWater}
+\include{RRDScenarioSelection}
+\include{DesignGeometryAdaption}
 
-\section{Purpose and scope of this document} \label{sec:PurposeAndScope}
+%-----------------------------------------------------------------------------
 
-This document contains the functional design for the \ProgramName, a computational engine for the automated calculation of the strength of dikes.
-DAM was developed by Deltares with and for STOWA for all water authorities.
-This document describes requirements and functional design of \ProgramName. 
-What will actually will be implemented depends on the requirements of the clients using this \ProgramName.
-If some functionality is not (yet) needed, then that part does not need to be implemented. 
-
-\subsection{Future options}
-\label{sec:FutureOptions}
-As mentioned above this document contains some options that will not be implemented in the first release, but are foreseen to be implemented in the near future. Therefore although sometimes a reference will be made to these options, these will not be described in detail yet.
-
-That applies in particular to the following subjects:
-\begin{itemize}
-	\item NWO module("Niet Waterkerende Objecten")
-	\item WBI failure mechanisms (Piping, Macrostability)
-\end{itemize}
-\section{Other system documents} 
-\label{sec:SystemDocuments}
-
-The full documentation on the program comprises the following documents.
-
-\renewcommand{\arraystretch}{1.3}
-
-\begin{table}[H]
-%\caption{xxx}
-%\label{xxx}
-\begin{tabular}{|p{40mm}|p{\textwidth-40mm-24pt}|} \hline
-\textbf{Title} & \textbf{Content} \\ \hline
-\ProgramName - Architecture Overall \newline \citep{DAM_ArchitectureOverall} & Description of overall architecture of the \ProgramName and its components. \\ \hline
-\ProgramName- Functional Design (this document)  \newline  \citep{DAMEngine_FunctionalDesign} & Description of the requirements and functional design. \\ \hline
-\ProgramName - Technical Design\newline \citep{DAMEngine_TechnicalDesign}& Description of the implementation of the technical design of \ProgramName. \\ \hline
-\ProgramName - Technical documentation \newline \citep{DAMEngine_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
-\ProgramName - Test Plan \newline \citep{DAMEngine_TestPlan} & Description of the different regression and acceptation tests, including target values.  \\ \hline
-\ProgramName - Test Report \newline \citep{DAMEngine_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
-Architecture Guidelines \newline \citep{ArchitectureGuidelines} & Architecture guidelines that are used by DSC-Deltares. \\ \hline
-\end{tabular}
-\caption{\small \ProgramName system documents.}
-\label{table-SystemDocuments}
-\end{table}
-
-\section{Document revisions}
-
-\section{Document revisions}
-\label{sec:DocumentRevisions}
-\subsection{Revision 0.1}
-\label{sec:Revision01}
-First concept of the document.
-
-\chapter{Non-functional requirements}
-
-\chapter{Functional requirements}
-
-Main purpose of the \ProgramName
-The \ProgramName gets data from DAM Clients, combines this data to calculation input and make serially calculations with one ore more kernels and generates output.
-
-\section{REQ Data.Format}\label{sec:REQDataFormat}
-The \ProgramName has a defined format for the data input, so DAM Clients know how to arrange the input data.
-
-\section{REQ Data.Content}\label{sec:REQDataContent}
-The \ProgramName has a defined content for the data input, so DAM Clients know how to arrange the input data.
-
-\section{REQ Data.Combination}\label{sec:REQDataCombi}
-The \ProgramName combines data per location when data is provide in GIS-files. Locations are defined by RD-coordinates.
-
-\section{REQ Data.Generation.Geometry}\label{sec:REQDataGenerationGeometry}
-The \ProgramName can combine a surface line with a subsoil scenario. The result is a geometry, usable for the failure mechanism Macrostability. 
-
-section{REQ Data.Generation.Waterpressures}\label{sec:REQDataGenerationWater}
-The \ProgramName can combine the hydraulic data with a subsoil scenario. The result is a schematization of the waterpressures, usable for the failure mechanisms Piping and Macrostability. 
-
-\section{REQ Calc.Type}\label{sec:REQCalcType}
-The \ProgramName provides three types of calculations:
-\begin{enumerate}
-	\item One-fold calculation: the input goes 'through' the kernel(s) and generates one main calculation answer (assessment);
-	\item Goal-seeking calculation: the input contains one variable and a desired outcome, the answer is the variable sufficient for the goal (design);
-	\item Time-lapsed calculation; calculations are made as time serie (operational).
-\end{enumerate}
-
-More specified; the \ProgramName provides the following calculation types, so the DAM Clients can provide this functionality.
-\begin{itemize}
-	\item Assessment general
-	\item Assessment regional dikes
-	\item Operational calculation from sensor data
-	\item Design of geometry, given required safety factor: Design-Geometry
-	\item Design of normative NWO-location, given dimensions of NWO and required safety factor: Design-NWO
-\end{itemize}
-
-\section{REQ Calc.Assess.General}\label{sec:REQCalcAssessGeneral}
-The DAM engine provides a Factor of safety. This may be one calculation or several. More than one calculation becames available when using several locations and/or several scenarios.
-
-\section{REQ Calc.Assess.Loadscenarios}\label{sec:REQCalcAssessLoadscenarios}
-The DAM engine must be able to calculate several load scenarios with different input data per location.
-
-\section{REQ Calc.Assess.Regional}\label{sec:REQCalcAssessRegional}
-For the assessment of regional dikes, \ProgramName must calculate several assessment scenarios (RRD-scenario), depending on:
-  
- \begin{itemize}
-	\item the type embankment (peat/other); green block in \autoref{fig:RRDClay} and \autoref{fig:RRDPeat};
-	\item the hydraulic shortcut (yes/no); brown block in \autoref{fig:RRDClay}, \autoref{fig:RRDPeat} and in detail in \autoref{fig:HydraulicShortcut};
-  \item the uplift situation (yes/no); purple blocks in \autoref{fig:RRDClay} and blue blocks in \autoref{fig:RRDPeat}.
-\end{itemize}
-
-This results in a variation of RRD scenarios, summed up in \autoref{tab:RRDScenarios}
-
-\begin{figure}[H]
-  \begin{center}
-    \includegraphics[width=15cm]{pictures/RRDClay.png}
-  \end{center}
-  \caption{Flowchart of embankments other than peat}
-  \label{fig:RRDClay}
-\end{figure}
-
-
-\begin{figure}[H]
-  \begin{center}
-    \includegraphics[width=15cm]{pictures/RRDPeat.png}
-  \end{center}
-  \caption{Flowchart of embankments of peat}
-  \label{fig:RRDPeat}
-\end{figure}
-
-\begin{figure}[H]
-  \begin{center}
-    \includegraphics[width=15cm]{pictures/HydraulicShortcut.png}
-  \end{center}
-  \caption{Flowchart of hydraulic shortcut}
-	\label{fig:HydraulicShortcut}
-\end{figure}
-
-
-\begin{table}[H]
-\centering
-\begin{tabular}{|p{18mm}|p{37mm}|p{20mm}|p{20mm}|p{\textwidth-105mm-36pt}|}
-\hline
-\textbf{RRD Scenario} & \textbf{Condition} & \textbf{Hydraulic Shortcut} & \textbf{Uplift} & \textbf{Model} \\ \hline
-1 & Dry	& yes & yes & Uplift \\ \hline
-2 & Dry & no & yes & Uplift \\ \hline
-3 & Wet	& yes & yes & Uplift \\ \hline
-4 & Wet	& no & yes & Bishop \\ \hline
-5 & Dry	& yes & yes & Bishop \\ \hline
-6 & Dry & no & yes & Bishop \\ \hline
-7 & Wet	& yes & yes & Bishop \\ \hline
-8 & Wet	& no & yes & Bishop \\ \hline
-9 & Dry	& yes/no & yes & Horizontal equilibrium \\ \hline
-10 & Wet & yes/no & yes & Piping \\ \hline
-11 & Dry & yes/no & yes & Piping \\ \hline
-\end{tabular}
-\caption{RRD scenarios}
-\label{tab:RRDScenarios}
-\end{table}
-
-
-\section{REQ Calc.Operational.Sensor}\label{sec:REQOperationalSensor}
-The DAM Engine must be able to use sensor data as input for the generation of water pressures.
-
-\section{REQ Calc.Design.Geometry}\label{sec:REQDesignGeometry}
-The DAM engine must be able to generate new profiles (surfacelines) based on desired Factor of safety.
-
-\section{REQ Calc.Design.NWO}\label{sec:REQDesignNWO}
-This will not be part of the first implementation of DAM Engine and therefor this paragraph has
-not yet been written.
-
-\section{REQ Failuremechanism}\label{sec:REQFailuremechanism}
-
-The \ProgramName provides calculations for following failure mechanisms, so the DAM Clients can provide this functionality.
-\begin{enumerate}
-	\item Macrostability inwards;
-	\item Macrostability outwards;
-	\item Piping;
-\end{enumerate}
-
-\section{REQ Output.format}\label{sec:REQOutputFormat}
-The \ProgramName has a defined format for the data output, so DAM Clients know how to present the output data.
-
-
-\chapter{REQDataGenerationWater}\label{sec:REQDataGenerationWater}
-
-The \ProgramName can combine the hydraulic data with a subsoil scenario. The result is a schematization of the waterpressures, usable for the failure mechanisms Piping and Macrostability. 
-
-\section{Conditions under which the automatic generation works} \label{sec:Conditions}
-Under certain circumstances, the kernel must be able to produce the water pressures in the geometry. If the following circumstances are met, the water pressures will be schematized following the guidelines [Technisch Rapport Waterspanningen bij dijken (2004)] during a high water tide.
-
-The requirements to automatically produce water pressures are as follows:
-\begin{itemize}
-	\item Minimum of one and maximum of two aquifers;
-	\item The aquifers reach from one boundary to the other (CNS 8);
-	\item The generator only works if the high water table is on the left side.
-\end{itemize}
-
-\section{Procedure for schematisation of the water pressures}\label{sec:procedure}
-
-The steps for the schematization of the water pressures are:
-\begin{enumerate}
-	\item The schematisation of the phreatic plane (see \autoref{sec:frea-vlak}).
-	\item Initial schematisation of piezometric heads  (see \autoref{sec:ini_stijghoogten}).
-	\item Checking for uplift (see \autoref{sec:contr_opdrijf}).
-	\item Definitive schematisation of pore pressures  (see \autoref{def_wsp}).
-\end{enumerate}
-
-\section{Schematisation of the phreatic plane}\label{sec:frea-vlak}
-There are currently two different approaches to the schematisation of the position of the phreatic plane: :  
-\begin{enumerate}
-	\item ExpertKnowledgeRRD
-	\item ExpertKnowledgeLinearInDike
-\end{enumerate}
-
-The schematisation method can be selected by the user in the base data (attribute: PLLineCreationMethod). The schematisation method and the associated values can be defined at the location level.
-
-The phreatic plane is referred to as Piëzometric Line 1 (PL1). 
-
-\subsection {ExpertKnowledgeRRD}
-The ExpertKnowledgeRDD method sets out the location of the phreatic plane at a maximum of 6 points: A to F. \autoref{fig:PL1_RRD}	lists these points. The level of the phreatic plane is defined by entering a number of vertical offsets relative to the outer water level or the ground level. \Autoref{tab:OffsetRRD} lists for each point how it is determined/recorded. The location of the phreatic plane between the points is determined on the basis of linear interpolation. 
-
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=0.5\textwidth]{pictures/PL1_RRD.png}
-	\caption{Schematisation freactic line (PL1) Macrostability inward using ExpertKnowledgeRRD}
-	\label{fig:PL1_RRD}
-\end{figure}
-
-\begin{table}[H]
-	\centering
-		\begin{tabular}{ |p{25mm} |p{100mm} |}
-    \hline
-\textbf{Punt}	& \textbf{Elevation determined by}	\\ \hline
-\textit{A} & Intersection of the water level with the outer slope (determined automatically) \\ \hline
-\textit{B} & Outer water level – stated offset \\ \hline
-\textit{C} & Outer water level – stated offset \\ \hline
-\textit{D} & Ground level shoulder base inside – stated offset\\ \hline
-\textit{E} & Ground level  inner toe – stated offset\\ \hline
-\textit{F} & Intersection of polder level with ditch (is determined automatically). \\ \hline
-		\end{tabular}
-	\caption{Parameters for each schematisation point used to locate the phreatic plane in the ExpertKnowledgeRRD schematisation option}
-	\label{tab:OffsetRRD}
-\end{table}
-
-Lower levels relative to the reference point/plane are stated as positive values. When schematising a rise in the phreatic plane under the crest, the offset are stated as a negative value. 
-
-
-\subsection {ExpertKnowledgeLineairDike}
-Here, the phreatic plane starts where the outer water level (Point A in \autoref{fig:PL1_Lineair} intersects the outer slope. It then continues in a straight line to point E and then to point F. 
-
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=0.5\textwidth]{pictures/PL1_Lineair.png}
-	\caption{Schematisation freactic line (PL1) Macrostability inward using ExpertKnowledgeLineair}
-	\label{fig:PL1_Lineair}
-\end{figure}
-
-
-\subsection{Particular cases} \label{sec:ParticularCases}
-
-The checks below apply to the four scenario's.
-
-\paragraph*{Free water}
-The procedure must check that the phreatic plane along the dike does not extend beyond the slope. If this the case, the location is automatically adapted to follow the surface level one centimeter lower. \\
-Free water in the polder side is allowed. However the polder water level is limited by the surface level outside (right geometry boundary).
-
-\paragraph*{No ditch, no shoulder}
-If there is no shoulder, point D will be omitted. If there is no ditch, the offset at point E will be continued with a limit of 1 cm below the surface line.
-
-\paragraph*{Phreatic line goes up}
-The procedure must ensure that the location of the phreatic plane is not below the stated polder level at points D and E as a result of the stated offsets. If this is the case, the location of the phreatic plane will automatically be matched to the polder level. In addition, the procedure must ensure that the phreatic plane at points D and E is not higher than at the preceding points. Point C may be higher than point B.
-
-\subsection{Minimum values below dike crest} \label{sec:MinimumValues}
-The phreatic levels at points B and C is limited by user-defined minimal values:
-\begin{itemize}
-	\item Z$_{\text{min;crest river}}$, the minimum value below the dike top at river;
-	\item Z$_{\text{min;crest polder}}$, the minimum value below the dike top at polder.
-\end{itemize}
-
-The minimum value below point B when point B does not correspond to the dike top at river must be deduced by interpolation or extrapolation between points (X$_{\text{crest river}}$; Z$_{\text{min;crest river}}$) and (X$_{\text{crest polder}}$; Z$_{\text{min;crest polder}}$.
-
-
-\section {Initial schematisation of piezometric heads}\label{sec:ini_stijghoogten}
-\ProgramName can manage a maximum of two aquifers. \ProgramName also takes the ‘penetration layer’ (TAW, 2004) into account. For the time being, this option works only with 1D soil profiles. If the calculations have to be made without a penetration layer, a value of 0 should be entered (attribute: PenetrationLength).
-
-\ProgramName defines the aquifers from bottom to top (in the direction of the surface). A piezometric line (PL3) is assigned to the bottom layer (which is also an aquifer) (\autoref{fig:wsp_1WL}). The pore pressures in the penetration layer are schematised using PL2. PL4 will be allocated to any additional aquifer. \autoref{tab:piezolijnen} gives an overview of the various piezometric lines and associated schematisati
-on.
-
-If several aquifers are stacked in succession one above the other, \ProgramName will allocate the same PL to all of them, assuming a hydrostatic range for the pore pressures. The separation between the aquifer and cohesive layer is then determined by the top of the highest aquifer in the stack.
-
-For the purposes of the stability calculations, \ProgramName schematises the piezometric heads in the vertical direction using linear interpolation in the soft layers. A hydrostatic range is assumed in the dike body, the soil layers where the phreatic plane is located and the aquifers. 
-
-\begin{table}[H]
-	\centering
-		\begin{tabular}{ |p{25mm} |p{100mm} |}
-    \hline
-\textbf{PL}	& \textbf{Description}	\\ \hline
-\textit{PL1} & Freatische lijn. Phreatic line. For stability calculations with a stationary phreatic plane. The  schematisation for PL1 is described in \autoref{sec:frea-vlak}\\ \hline
-\textit{PL2} & The pore pressure at the top of the penetration layer. The PL2 is not affected by the piezometric head in the underlying aquifer and it is constant (in other words, there is no damping) over the entire width of the cross-section. The user enters the value for PL2 (attribute: HeadPL2), as well as the thickness of the penetration layer. DAM 1.0 uses the PL2 only if the thickness of the penetration layer >0 m.\newline
-Note: at present, the use of PL2 is still limited to 1D soil profiles.
-\\ \hline
-\textit{PL3} & Pore pressure in the bottom aquifer. The value can be entered (attribute: HeadPL3). If no value is entered, PL3 is considered to be the same as the outer water level stated in the scenarios (see section 2.6). 
-\newline
-The value for PL3 at the inner toe (\autoref{fig:dempingfactor}) depends on the stated damping factor (attribute: DampingPL3). This damping factor expresses the degree to which PL3 is damped to PL2. Zero means no damping (PL3 is constant). And the value 1 suggests full damping to PL2 (attribute: PL2). If no value has been entered for PL2, the polder water level will be used (attribute: PolderLevel). Beyond the inner toe, the PL3 declines to the polder level at a gradient to be stated (attribute: SlopeDampingPiezometricHeightPolderSide). The PL3 then matches the polder level. A value can be entered for the gradient of this PL slope. The default value is 0. This means there is no slope.  
- \\ \hline
-\textit{PL4} & Pore pressure in an intermediate aquifer (if present). The schematisation for PL4 is similar to that described for PL3. However, PL3 should be read as PL4.\newline
-Note: Both PL3 and PL4 use the same gradient for the slope of the PL line on the polder side.
-\\ \hline
-		
-	\end{tabular}
-	\caption{Overview and description of piezometric lines}
-	\label{tab:piezolines}
-\end{table}
-
-
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=1\textwidth]{pictures/wsp_1WL.png}
-	\caption{Schematisatie van waterspanningen in de situatie van \'e\'en watervoerende laag}
-	\label{fig:wsp_1WL}
-\end{figure}
-
-
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=1\textwidth]{pictures/dempingfactor.png}
-	\caption{Gebruik van dempingsfactor (f) en reductie pi\"ezolijn aan de polderzijde (X) voor schematisatie horizontaal stijghoogteverloop}
-	\label{fig:dempingfactor}
-\end{figure}
-
-
-\section {Controle op opdrijven}\label{sec:contr_opdrijf}
-Vanaf de binnenteen tot midden slootbodem, wordt door \ProgramName berekeningen gemaakt of er opdrijven optreedt. Hiervoor wordt de formule uit het VTV (2006) gebruikt en de initiële schematisatie van de stijghoogten (zie \autoref{sec:ini_stijghoogten})\newline
-
-\begin{equation}
-\label{eq_opdrukveiligheid}
-	opdrukveiligheid = \frac{\sigma_g}{\sigma_w}
-\end{equation}
-
-Als er geen sloot aanwezig is, worden de berekeningen tot de grens van het dwarsprofiel uitgevoerd. Indien er opdrijven wordt berekend, reduceert \ProgramName de PL3 of PL4 naar een waarde waarbij opdrijven net niet meer optreedt, of te wel labiel evenwicht (zie \autoref{fig:redPL})
-
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=1\textwidth]{pictures/redPL.png}
-	\caption{Reductie stijghoogte bij opdrijven. \ProgramName controleert van de binnenteen tot het einde van het profiel op opdrijven en past daarop de stijghoogte aan tot labiel evenwicht}
-	\label{fig:redPL}
-\end{figure}
-
-\section {Definitieve schematisatie waterspanningen}\label{def_wsp}
-Op basis van de initi\"ele generatie van de waterspanningen en controle op opdrijven wordt de definitieve schematisatie van de waterspanningen aangemaakt. Hierbij wordt in horizontale richting lineair ge\"interpoleerd tussen de verschillende (berekende) knikpunten in de PL lijnen.
-
-
-%------------------------------------------------------------------------------
-%\chapter{System Architecture} \label{chapterSystemArchitecture}
-%
-%This chapter contains diagrams describing the modules and submodules of the \ProgramName and how they interact. 
-%In \autoref{chapterModuleDescription} a short description of each module/submodules is given.
-%
-%\section{DAM components} \label{sec:DamComponents}
-%
-%\ProgramName is part of the whole DAM system that contains several components. 
-%Please see \autoref{fig-DamComponents} for an overview of the components of DAM. 
-%In \citep{DAM_ArchitectureOverall} a description of the overall architecture of the DAM system can be found.
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DamComponents.pdf}
-  %\end{center}
-%
-  %\caption{\small \ProgramName and its components.}
-  %\label{fig-DamComponents}
-%\end{figure}
-%
-%The arrows illustrate the dependencies of the components.
-%
-%\section{\ProgramName data flow}
-%\label{sec:ProgramNameDataFlow}
-%Please see \autoref{fig-DAMMainDataflow} for an overview of the data flow within the DAM system. 
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMMainDataflow.pdf}
-  %\end{center}
-%
-  %\caption{\small \ProgramName and its components.}
-  %\label{fig-DAMMainDataflow}
-%\end{figure}
- %
-%The red arrows illustrate the dataflow between the main DAM components. \newline
-%As can be seen the data exchange between the \ProgramName and the \kernel (bottom of the picture) is done through the API that is defined by the \kernel.
-%The data exchange between the \ProgramName and the DAM client (top of the picture) is done through XML files (one for input and one for output), which are well defined by XML schemas (XSD's).
-%\section{\ProgramName components} 
-%\label{sec:DAMEngineComponents}
-%
-%The \ProgramName itself also consists of several modules.
-%These can be seen in see \autoref{fig-DAMEngineComponents} 
-%
-%All of the submodules inside the Main Modules are completely independent.
-%All of the submodules inside the Supporting Modules are also independent. 
-%But all these submodules can be used by each of the main modules. 
-%The arrows show the allowed dependencies.
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=16cm]{pictures/DAMEngineComponents.pdf}
-  %\end{center}
-%
-  %\caption{\small \ProgramName and its components.}
-  %\label{fig-DAMEngineComponents}
-%\end{figure}
-%
-%\section{\ProgramName sequence and activity diagrams} \label{sec:DAMEngineSequenceActivityDiagrams}
-%In this section the sequence diagrams, showing the use of the submodules are shown. 
-%For each sequence diagram a corresponding activity diagram is also shown
-%
-%\subsection{Dikes assessment}
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMEngineSequenceAssessment.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Assessment sequence diagram.}
-  %\label{fig-DAMEngineSequenceAssessment}
-%\end{figure}
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=8cm]{pictures/DAMEngineActivityAssessment.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Assessment activity diagram.}
-  %\label{fig-DAMEngineActivityAssessment}
-%\end{figure}
-%
-%\subsection{Dikes assessment Regional}
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMEngineSequenceAssessmentRegional.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Regional assessment sequence diagram.}
-  %\label{fig-DAMEngineSequenceAssessmentRegional}
-%\end{figure}
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=9cm]{pictures/DAMEngineActivityAssessmentRegional.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Regional assessment activity diagram.}
-  %\label{fig-DAMEngineActivityAssessmentRegional}
-%\end{figure}
-%
-%\subsection{Dikes operational}
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMEngineSequenceOperational.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Operational sequence diagram.}
-  %\label{fig-DAMEngineSequenceOperational}
-%\end{figure}
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=8cm]{pictures/DAMEngineActivityOperational.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Operational activity diagram.}
-  %\label{fig-DAMEngineActivityOperational}
-%\end{figure}
-%
-%\subsection{Dikes design}
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMEngineSequenceDesign.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Design sequence diagram.}
-  %\label{fig-DAMEngineSequenceDesign}
-%\end{figure}
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=8cm]{pictures/DAMEngineActivityDesign.pdf}
-  %\end{center}
-  %\caption{\small \ProgramName Design activity diagram.}
-  %\label{fig-DAMEngineDesignAssessment}
-%\end{figure}
-%
-%\subsection{Dikes NWO calculation}
-%This will not be part of the first implementation of \ProgramName and therefor this paragraph has not yet been written.
-%
-%%------------------------------------------------------------------------------
-%\chapter{Architectural Choices} \label{chapterArchitecturalChoices}
-%\section{Architecture guidelines}
-%\label{sec:ArchitectureGuidelines}
-%
-%Within Deltares, DSC, a document is being written about Archtitecture Guidelines \citep{ArchitectureGuidelines}. 
-%Although it is still a work in progress \ProgramName should adhere to those guidelines.
-%More specific guidelines are added in the following sections of this chapter.
-%
-%\section{Design principles} \label{sec:DesignPrinciples}
-%\begin{itemize}
-	%\item No circular references between objects. 
-	%When it is really unavoidable, then do it through a generic interface (e.g.\ IParentObject)
-	%\item The calculation will support parallellization. 
-	%So do not use global variables and avoid using statics.	
-	%\item Failure mechanisms will be connected through wrapper classes, which will share a common IFailureMechanism interface
-	%\item Surfaceline designer classes will share a common ISurfacelineDesigner interface
-	%\item The \ProgramName must provide progress information of the calculation, so clients of the \ProgramName can show a progressbar
-	%\item The \ProgramName must provide the possiblity to abort a calculation within a reasonable timespan.
-	%\item There should be no User Interface elements shown anytime during the calculation.
-%\end{itemize}
-%
-%\section{Programming environment} \label{sec:ProgrammingEnvironment}
-%The \ProgramName will be developed in C\# with the .NET 4.5 framework. The development environment will be Visual Studio 2015.
-%
-%\section{Error handling} \label{sec:ErrorHandling}
-%Errors within the \ProgramName are handled through the standard exception handling of the .NET framework. Error messages must contain as much information as possible, so a user can trace back the error to the input data. \newline
-%Errorhandling with a \kernel is done through the mechanism that is supplied by the API of the specific kernel. \newline
-%Errorhandling with DAM Client is done by passing the error messages as part of the output XML file. \newline
-%In fact it is the same mechanism that is used for exchanging the regular data (input and output), as shown in \autoref{fig-DAMMainDataflow}. 
-%\newline
-%\newline
-%The \ProgramName should be able to issue the error messages in different languages.
-%In the first implementation only the 2 following languages will be supported:
-%\begin{itemize}
-	%\item Dutch (NL)
-	%\item English (UK)
-%\end{itemize}
-%For translations, you want to adhere to the standard Windows mechanism with language resource dll's. 
-%But that would make it impossible to use the engine at any other platform. 
-%So preferably it should use an intermediate layer instead (through an Interface) which in turn can implement the platform specific implementation as required. Only the Windows mechanism will be implemented at first.
-%Note: the current implementation of DAM uses another mechanism for translations, that will not be applied here, because it is dependent on the DSL (Delta Shell Light) library, which will not be used for the \ProgramName. 
-%
-%\section{Libraries and components} \label{sec:ExternalLibrariesAndComponents}
-%\ProgramName uses other libraries and components. 
-%
-%For now we foresee only the use of the following libraries:
-%\begin{itemize}
-	%\item Failure mechanisms.
-	%\item Math.NET.
-%\end{itemize}
-%Other libraries may be used under the condition that they are open source and free components, that are free to redistribute. \newline
-%All libraries should be listed in a manifest accompanying the release of \ProgramName. The list should also specify under which license each specific library is distributed. 
-%
-%Note: the current implementation of DAM uses the DSL (Delta Shell Light) library. This library will explicitly not be used for the \ProgramName, because this library is being made obsolete. 
-%
-%
-%\subsection{Failure mechanisms} \label{sec:FailureMechanisms}
-%The failure mechanisms are treated as external libraries. 
-%Some failure mechanisms were part of the source of the original DAM program. 
-%With the new architecture of \ProgramName this will longer be the case. 
-%These failure mechanisms will be placed in a DAM failure mechanisms library, that is not part of \ProgramName anymore.
-%The following failure mechanisms are currently supported by the original DAM program:
-%\begin{itemize}
-	%\item Piping Bligh  (not opensource)
-	%\item Piping Sellmeijer VNK  (not opensource)
-	%\item Piping Sellmeijer 2 forces  (not opensource)
-	%\item D-Geo Stability inward (not opensource, but commerical)
-	%\item D-Geo Stability outward (not opensource, but commerical)
-%\end{itemize}
-%
-%After the original failure mechanisms have been implemented, the new WBI failure mechanisms will be added:
-%\begin{itemize}
-	%\item WTI Piping
-	%\item WTI Macrostability inward
-%\end{itemize}
-%
-%\subsection{Math.Net} \label{sec:MathNet}
-%Math.Net is a library that is distributed under the MIT/X11 license. Therefore it meets the conditions about open source and free redistribution.
-%
-%
-%%------------------------------------------------------------------------------
-%\chapter{Data Model}  \label{chapterDataModel}
-%This chapter contains diagrams describing the main data objects of the \ProgramName and their relation to each other. 
-%In \autoref{chapterDataDescription} a short description of these data objects is given.
-%
-%\section{Main Data Model} \label{sec:MainDataModel}
-%
-%The main data model can be seen in see \autoref{fig-DAMEngineDataModelMain} 
-%It is not fully worked out, but just a global overview. 
-%The details will be filled in when programming the \ProgramName. 
-%This is because we do not intend to write a big upfront design.
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=15cm]{pictures/DAMEngineDataModelMain.pdf}
-  %\end{center}
-%
-  %\caption{\small \ProgramName main data model.}
-  %\label{fig-DAMEngineDataModelMain}
-%\end{figure}
-%
-%
-%
-%\section{Location} \label{sec:Location}
-%
-%The data model of the Location class can be seen in see \autoref{fig-DAMEngineDataModelLocation} 
-%
-%\begin{figure}[H]
-  %\begin{center}
-    %\includegraphics[width=12cm]{pictures/DAMEngineDataModelLocation.pdf}
-  %\end{center}
-%
-  %\caption{\small \ProgramName Location object.}
-  %\label{fig-DAMEngineDataModelLocation}
-%\end{figure}
-%
-%%------------------------------------------------------------------------------
-%\chapter{Data Description}  \label{chapterDataDescription}
-%
-%\section{Type enumerations} \label{sec:TypeEnumerations}
-%\subsection{MainMechanismType}
-%\begin{itemize}
-	%\item Macrostability inward
-	%\item Macrostability outward
-	%\item Piping
-%\end{itemize}
-%
-%\section{Scenarios} \label{sec:Scenarios}
-%Scenarios are widely (a)bused within DAM. It is good to define in which context scenarios are used and how they are to be called. Simply using the word sceanrio is not enough.
-%Within DAM we have 3 types of scenarios:
-%\begin{itemize}
-	%\item Subsoil scenario
-	%\item Load scenario
-	%\item Regional scenario
-%\end{itemize}
-%
-%\subsection{Subsoil scenario}
-%\label{sec:SubSoilScenario}
-%Used as part of the stochastic subsoil schematization. 
-%A subsoil scenario defines a possible 1D- or 2D-profile that applies to a certain location.
-%
-%\subsection{Load scenario}
-%\label{sec:LoadScenario}
-%Used for Design calculation. 
-%In a design calculation a new surfaceline is designed for a location, based on a target failure factor (e.g. due to new requirements), or load (e.g. a higher waterlevel).
-%
-%\subsection{Regional scenario}
-%\label{sec:RegionalScenario}
-%For regional assessments there are certain scenarios that have to be evaluated, depending on the circumstances (e.g. drought, type of dike etc.). Part of the assessment is the determination which scenarios have to be evaluated and then calculating those scenarios.
-%
-%\section{Main Data Model} \label{sec:MainDataModelDescription}
-%
-%\subsection{Input}
-%\paragraph*{DamProjectType}
-%\begin{itemize}
-	%\item Assessment
-	%\item Assessment regional
-	%\item Operational
-	%\item Design
-	%\item NWO
-%\end{itemize}
-%\paragraph*{DamProjectCalculationSpecification}
-%This class specifies which failuremechanism is to be calculated and it also contains the specific options for the selelected mechanism (e.g.\ which calculation model)
-%\paragraph*{Locations}
-%This is a collection of locations, with each location containing the location specific data.
-%\paragraph*{Soil Segments}
-%This is a collection of soil segments, with each segment containing the subsoil data for a specific failure mechanism.\textbf{}
-%\paragraph*{Soils}
-%This is a collection of soils, with each soil containing the soil parameters needed for the calculation of all failure mechanisms.\textbf{}
-%
-%\subsection{Output}
-%\paragraph*{CalculationResults}
-%A calculation result holds the result for a specific location, a specific failure mechanism, and a specific subsoil scenario of a specific segment defined in the location data.
-%\paragraph*{CalculationMessages}
-%These are all the message that are generated by the calculation. A message must contain as much information as possible to trace back the information tho the input data (e.g.\ a specific location, a specific failure mechanism, and a specific subsoil scenario of a specific segment defined in the location data).
-%
-%\section{Location} \label{sec:LocationDescription}
-%\paragraph*{SoilSegment}
-%A soil segment contains the subsoil data for a specific failure mechanism.
-%\paragraph*{SurfaceLine}
-%A surfaceline describes the dike profile in a specific location. In the Design calculation it can also be the new dike profile, which can meet design criteria in a specific load scenario.
-%\paragraph*{WaternetOptions}
-%The options that support the creation of a waternet in a specific location.
-%\paragraph*{DesignOptions}
-%The options that will be used in the Design calculation (e.g.\ how to design a shoulder when needed).
-%\paragraph*{SensorData}
-%The sensor data can be used to define a waternet based on live sensor data. This sensor data holds information about ID and location of the sensor. The actual sensor readings are defined as timeseries readings for each sensor in each location.
-%\paragraph*{LoadScenario}
-%Used for Design calculation. A load scenario contains the following items:
-%\begin{itemize}
-	%\item Riverlevel low
-	%\item Riverlevel high
-	%\item Dike table height
-	%\item Required safety factor for each specified failure mechanism
-	%\item Uplift criterium for each specified failure mechanism
-	%\item Waternet options for each specified failure mechanism
-%\end{itemize}
-%\paragraph*{IFailureMechanismOptions}
-%Specific options for each location for each failure mechanism.
-%%------------------------------------------------------------------------------
-%\chapter{Module Description}  \label{chapterModuleDescription}
-%
-%\section{\ProgramName main modules} \label{sec:DAMEngineMainModules}
-%
-%\subsection{Assessment Dikes}
-%This module performs an assessment for general dikes (e.g. primary dikes).
-%\paragraph*{Primary assessment calculation}
-%This is the main submodule of the primary assessement. 
-%This submodule contains the main loop of the calculation.
-%
-%\subsection{Assessment Regional Dikes}
-%This module performs an assessment for regional dikes.
-%\paragraph*{Regional assessment calculation}
-%This is the main submodule of the regional assessement. 
-%This submodule contains the main loop of the calculation.
-%\paragraph*{Regional scenario selector}
-%This submodule generates all the scenarios that have to be evaluated for a specific location. 
-%The scenarios are selected based on the local conditions.
-%\paragraph*{Regional schematization factor calculator}
-%This submodule calculates the schematization factor in a location based on all results of all scenarios in a location.
-%
-%\subsection{Design Dikes}
-%This module performs an design calculation for all types of dikes.
-%\paragraph*{Primary design calculation}
-%This is the main submodule of the primary design calculation. 
-%This submodule contains the main loop of the calculation.
-%
-%\subsection{Operation module}
-%This module performs a time series based calculation for all types of dikes.
-%\paragraph*{Time series based calculation}
-%This is the main submodule of the time series based calculation. 
-%This submodule contains the main loop of the calculation.
-%
-%\subsection{NWO Calculation}
-%This module performs an NWO (Niet Waterkerende Objecten) calculation for primary dikes.
-%\paragraph*{Primary NWO calculation}
-%This is the main submodule of the NWO calculation. 
-%This submodule contains the main loop of the calculation.
-%
-%\section{\ProgramName supporting modules} \label{sec:DAMEngineSupportingModules}
-%\subsection{Failure mechanism wrapper interface}
-%For each \kernel  a specific wrapper will be written. This wrapper must implement a specific interface, so the \ProgramName can support the use of the \kernel. 
-%The interface that must be implemented is IFailureMechanism.\newline
-%Example:
-%Lets say that for the failure mechanism piping we have 3 kernels: Bligh, Sellmeijer and VNK. 
-%Then for each of these kernels a calculation wrapper has to be written.\newline
-%Another example: 
-%D-Geo Stability kernel has the ability to calculate the failure mechanism macrostability inwards and the failure mechanism macrostability outwards. 
-%In this case 2 wrappers (one for each failure mechanism) are needed for this single kernel.\newline
-%The next methods are defined in the IFailureMechanism interface
-%\begin{itemize}
-	%\item Prepare()
-	%\item Validate()
-	%\item Execute()
-	%\item Design()
-	%\item PostProcess()
-	%\item RegisterProgressFeedback()
-	%\item RegisterAbortCheck()
-%\end{itemize}
-%
-%\subsubsection{Prepare}
-%\label{sec:Prepare}
-%The purpose of this method is to fill a dataobject that implements the IKernelDataInput interface. This dataobject will be needed for the other methods in this interface.  
-%This method has one parameter:
-%\begin{itemize}
-	%\item Input
-%\end{itemize}
-%It returns IKernelDataInput. This method fills the IKernelDataInput object from the main input data object (Input).
-%In IKernelDataInput the data is filled that is needed by the specific \kernel data. 
-%Each \kernel wrapper will have its own implementation of IKernelDataInput.
-%
-%\subsubsection{Validate}
-%\label{sec:Validate}
-%The purpose of this method is to validate the data that will be used as input for the failure mechanism.
-%This method has 2 parameters:
-%\begin{itemize}
-	%\item IKernelDataInput (kernel input data) 
-	%\item ValidationMessageList (a list of messages produced by the validation)
-%\end{itemize}
-%It returns an integer:
-%0: no errors. A calculation is possible. It is possible that there are warning messages.
-%>0: number of error messages that prevent a calculation.
-%
-%\subsubsection{Execute}
-%\label{sec:Execute}
-%This method performs the actual calculation of the failure mechanism,
-%This method has 2 parameters:
-%\begin{itemize}
-	%\item IKernelDataInput (kernel input data) 
-	%\item ErrorMessageList (a list of error messages produced by the calculation)
-%\end{itemize}
-%It returns IKernelDataOutput. IKernelDataOutput contains the calculation results of the \kernel data. 
-%Each \kernel wrapper will have its own implementation of IKernelDataOutput.
-%
-%\subsubsection{Design}
-%\label{sec:Design}
-%This method implements a design calculation. Based on certain design parameters (e.g. target failure factor, new load parameters, design strategies, etc.) a new design is made for the input data (e.g. a new surfaceline).
-%This method has 3 parameters:
-%\begin{itemize}
-	%\item IKernelDataInput (kernel input data) 
-	%\item IKernelDesignDataInput (definition of the design parameters) 
-	%\item ErrorMessageList (a list of error messages produced by the design calculation)
-%\end{itemize}
-%It returns a IKernelDesignDataOutput. IKernelDesignDataOutput contains the adapted input data (a.g. a new designed surfaceline) and other design results (e.g. number of iterations needed, success or failure etc.). \newline
-%Based on the given criteria a new design is determined, which will meet the required criteria. If such a design is not possible, that will be reported back.
-%
-%
-%\subsubsection{PostProcess}
-%\label{sec:PostProcess}
-%This method has 2 parameters
-%\begin{itemize}
-	%\item IKernelDataOutput (kernel output data) 
-	%\item Output (the \ProgramName output data)
-%\end{itemize}
-%This method fills the \ProgramName Output object with the results of the \kernel (IKernelDataOutput).
-%\subsubsection{RegisterProgressFeedback}
-%\label{sec:RegisterProgressFeedback}
-%This method registers a callback function into the \kernel wrapper that can report back progress status from the \kernel wrapper to the calling application. The calling application provides the callback function that should be called.
-%\subsubsection{RegisterAbortCheck}
-%\label{sec:RegisterAbortCheck}
-%This method registers a callback function into the \kernel wrapper. The calling application provides the callback function that should be called. If the function reports back that an abort was requested, the \kernel should abort the calculation and return to the calling application with an appropriate error message.
-%
-%\subsection{Failure mechanism wrapper implementations}
-%For now the next three implementations of failure mechanism wrappers are foreseen. In the future more can be added. Note also that for a specific failure mechanism multiple implementations can be created. E.g. Piping: 
-%\begin{itemize}
-	%\item piping Bligh
-	%\item piping Sellmeijer 2 forces
-	%\item piping Sellmeijer 4 forces
-	%\item piping VNK model
-%\end{itemize}
-%
-%\subsubsection*{Macrostability inwards}
-%Calculation wrapper for Macrostability inward. 
-%Note that (as already mentioned above) for each specific kernel implementation for a failure mechanism, a separate wrapper has to be build (e.g.\ Slope/W and D-Geo Stability)
-%\subsubsection*{Macrostability outwards}
-%Calculation wrapper for Macrostability outward.
-%\subsubsection*{Piping}
-%Calculation wrapper for Piping.
-%\subsection{Surfaceline designers}
-%A collection of surfaceline designers to support the design calculation. 
-%Each designer should adhere to the ISurfaceLineDesigner interface.
-%\subsubsection*{Surfaceline Designer Height}
-%Adapts the surfaceline by adding extra height to the dike crest.
-%\subsubsection*{Surfaceline Designer Slope}
-%Adapts the surfaceline by changing the slope of the dike on the inside.
-%\subsubsection*{Surfaceline Designer Shoulder}
-%Adapts the surfaceline by adding a shoulder or enlarging the shoulder on the inside of the dike.
-%\subsubsection*{Surfaceline Designer NWO}
-%Adapts the surfaceline by adding a NWO on a specific place in the surfaceline.
-%\subsubsection{Calculation Runner}
-%\paragraph*{Failure mechanism Calculation Runner}
-%This submodule calculates a specific failure mechanism by calling the IFailureMechanism interface of the wrapper implementation.
-%\subsubsection*{Design Calculation Runner}
-%This submodule performs a design calculation for a specific failure mechanism by calling the IFailureMechanism interface and several surfaceline designers through their ISurfacelineDesigner interface.
-%\subsubsection*{Operational Calculation Runner}
-%This submodule can perform a calculation based on sensor readings (as time-series). 
-%The load on the systems (the waternet) will be based on those sensor readings. This can be used in operational systems like DamLive.
-%\subsubsection*{Probabilistic Calculation Runner}
-%This submodule performs a probabilistic calculation for a specific location and failure mechanism. 
-%The outcome is a failure probability for that location and failure mechanism. 
-%\subsection{General submodules}
-%\subsubsection*{Geometry creator}
-%This submodule combines a surfaceline with a subsoil scenario. 
-%The output is a geometry that can be used by the failure mechanisms to perform a calculation.
-%\subsubsection*{Waternet creator}
-%A waternet describes the waterpressures in the dike embankment. 
-%The waterpressures are a result of the load on the system (outer waterlevel and polderlevel).
-%This submodule determines the waternet that will be used by the failure mechanism kernels. 
-%At first only the current DAM implementation will be used as a waternet creator. 
-%Later on new implementations can be made and applied. 
-%E.g.\ specific for each failure mechanism, or an implementation based on a numerical model like DgFlow.
-%\subsubsection{Scripting engine}
-%To enable advanced users to experiment with how the \ProgramName works a Python scripting engine is implemented as a submodule. 
-%The scripting engine has acces to the data model and the submodules through well defined interfaces. 
-%
-%%------------------------------------------------------------------------------
-%\chapter{Programming Interface}  \label{chapterProgrammingInterface}
-%This is the definition of the programming interface. 
-%The only way to communicate to the \ProgramName is through this interface.
-%
-%\textbf{TO DO: Add interface description}
-
-%------------------------------------------------------------------------------
-\chapter{Literature}  \label{chapterLiterature}
-
-\bibliography{../DAM_references/dam_references}
-
-
-
-
 \pagestyle{empty}
 \mbox{}
 
 %------------------------------------------------------------------------------
-\end{document}
+\end{document}
\ No newline at end of file
