So ware for the assessment of primary ood defences H -R · Title Hydra-Ring 16.3 Client Rijkswaterstaat Project 1230088.021 Reference 1230088-021-0SC-0071 Pages 106 Classification

WTI2017WTI2017

Hydra-ring

Software for the assessment of primary flood defences

Technical Design

TitleHydra-Ring 16.3

ClientRijkswaterstaat

Project1230088.021

Reference1230088-021-0SC-0071

Pages106

Classification

KeywordsWT12017, software, probabilistics, statistics, flood risk, design

SummaryThe Dutch primary flood defences are periodically assessed against statutory safety standards. Currently, policymakers are moving towards safety standards defined in terms ofmaximum allowable probabilities of flooding. To facilitate such a move, a new probabilisticframework for assessing the safety of flood defences is being developed within the projectWTI2017 (Wettelijk Toetslnstrumentarium 2017).

The new probabilistic framework is embedded in software that is developed within projectWT12017. The software consists of a user-interface ('Ringtoets') and a computational kernel('Hydra-Ring'). The computational kernel Hydra-Ring, the subject of this report, incorporatesthe probabilistic calculation schemes, the statistical treatment of hydraulic data and the failuremechanisms for flood defences.

The technical design of the computational core is described in this report. In this document,the algorithms are conceptually visualized by means of program structure diagrams as wellas UML-diagrams. Furthermore, a technical design is presented to ensure strict modularityof the software. The multiple libraries and the several failure mechanisms are set apart andcaptured in Hydra-Ring by means of either C#-wrappers or Fortran-wrappers.

Hydra-Ring runs on four different databases: the project database (PO) with user input data,the configuration database (CD) containing the setup of all failure mechanisms and modules, the hydraulic load configuration database (HLCO) containing the load data and multiplehydraulic region databases (HRO) containing the result output data for variables previouslycomputed by means of deterministic models such as WAQUA and SWAN.

References

Version Date Author Initials Review Initials Approval Initials1.0 Dec 2011 Rob Brinkman Marcel Annemargreet

Visschedijk de Leeuw2.0 Aug 2016 Guus Rangen Henri Steenbergen Jan-Aart van.. Twillert16.3 Dec 2016 Wauter Jan Klerk Edwin Spee ~S Jan-Aart van

Twillert

StatusFinal

TitelHydra-Ring 16.3

OpdrachtgeverRijkswaterstaat

Project1230088.021

Kenmerk1230088-021-0SC-0071

Pagina's106

Classificatie

Trefwoorden

WT12017, software, probabilistiek, statistiek, overstromingsrisico, ontwerp

Samenvatting

De Nederlandse primaire waterkeringen worden periodiek getoetst op basis van wettelijke velligheidsstandaarden. Thans is er een beleidsontwikkeling gaande die een verandering naarveiligheidsheidsstandaarden in termen van overstromingskansen beoogt. am deze verandering te faciliteren, wordt binnen het project WTI2017 (Wettelijk Toetslnstrumentarium 2017)een probabilistisch raamwerk opgezet voor de veiligheidstoets voor waterkeringen.

Het nieuwe probabilistische raamwerk is ingebed in software die momenteel in ontwikkelingis. De software bestaat uit een user-interface ('Ringtoets') en een rekenkern ('Hydra-Ring').De rekenkern Hydra-Ring, welke het onderwerp vormt van dit rapport, omvat probabilistischerekenschema's, de statistische behandeling van hydraulische data en faalmechanismen voorwaterkeringen.

Het technische ontwerp van de rekenkern is beschreven in dit rapport door middel van het visualiseren van algoritmes in schema's, programma structuur diagrammen en UML-diagrammen.Tevens wordt een technische ontwerp gepresenteerd om stricte modulariteit van de software te verzekeren. Meerdere bibliotheken en faalmechanismen zijn apart gezet en vervatin Hydra-Ring middels C#-wrappers of Fortran-wrappers.

Hydra-Ring draait op vier verschilIende databases: de project database (PO) voor invoerdata, the configuratie database (CD) voor de setup van faalmechanismen en modules, thebelasting configuratie database (HLCO) en de belasting regio databases (HRO) die de uitvoervan deterministische WAQUA-berekeningen en SWAN-berekeningen bevat.

Referenties

Versie Datum Auteur Paraaf Review Paraaf Goedkeuring Paraaf1.0 Dec 2011 Rob Brinkman Marcel Annemargreet

Visschedijk de Leeuw2.0 Aug 2016 Guus Rangen Henri Steenbergen Jan-Aart van

... Twillert16.3 Dec 2016 Wouter Jan Klerk Edwin Spee ~5 Jan-Aart van

Twillert

StatusOefinitief

Hydra-Ring 16.3

Probabilistics toolbox for the WTI2017

Technical Design

Version: 16.3Revision: 7326

31-08-2016

Hydra-Ring 16.3, Technical Design

Published and printed by:DeltaresBoussinesqweg 12629 HV DelftP.O. 1772600 MH DelftThe Netherlands

telephone: +31 88 335 82 73fax: +31 88 335 85 82e-mail: [email protected]: https://www.deltares.nl

Contact:Helpdesk WaterRijkswaterstaat WVLP.O. 22323500 GE UtrechtThe Netherlands

telephone: +31 88 797 7102www: http://www.helpdeskwater.nl

Copyright © 2016 DeltaresAll rights reserved. No part of this document may be reproduced in any form by print, photoprint, photo copy, microfilm or any other means, without written permission from the publisher:Deltares.

Contents

Contents

List of Figures vii

List of Tables ix

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose and scope of this document . . . . . . . . . . . . . . . . . . . . . 11.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 System design description 32.1 System components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Functionality for failure mechanisms . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Calculation scheme Ferry Borghes Castanheta (FBC) . . . . . . . . 42.2.2 Calculation scheme Numerical Time Integration (NTI) . . . . . . . . . 72.2.3 Calculation scheme Arbitrary Point in Time (APT) . . . . . . . . . . . 92.2.4 Compute the failure probability of a submechanism . . . . . . . . . . 112.2.5 Time scales and temporal evolution of load variables . . . . . . . . . 122.2.6 Parameter distributions and correlations . . . . . . . . . . . . . . . 132.2.7 Hydrodynamic models . . . . . . . . . . . . . . . . . . . . . . . . 142.2.8 Wave generation, load transformation and load model uncertainty . . 14

2.3 Functionality for combining failure probability contributions . . . . . . . . . . 152.3.1 Calculation scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 On the length of a section . . . . . . . . . . . . . . . . . . . . . . . 162.3.3 Ring computation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Preprocessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.1 Closure scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.2 The water system Easternscheldt . . . . . . . . . . . . . . . . . . . 25

2.4.2.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.2.2 Determine the exceedance probability curves . . . . . . . . 272.4.2.3 Determine an exceedance frequency curves . . . . . . . . 282.4.2.4 Calculate probability of tidal phase difference . . . . . . . . 302.4.2.5 Calculate probability of storm duration . . . . . . . . . . . 302.4.2.6 Calculate the probability of the water level OS11 . . . . . . 312.4.2.7 Calculate closure scenario probability . . . . . . . . . . . 332.4.2.8 Calculate water level uncertainty . . . . . . . . . . . . . . 352.4.2.9 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.3 The water system Dunes . . . . . . . . . . . . . . . . . . . . . . . 362.4.4 Eliminated effects of wind directions . . . . . . . . . . . . . . . . . 37

2.5 Non-functional aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.1 Data-integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2 Data-inconsistency . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.3 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.4 Plausibility checks . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.5 Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.6 Data recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.7 Parallellisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Interface design description 453.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2 Module dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3 Plugin for failure mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 473.4 Implementation of new failure mechanisms . . . . . . . . . . . . . . . . . . 50

Deltares iii


3.4.1 Step 1a: Create a Fortran wrapper . . . . . . . . . . . . . . . . . . 503.4.2 Step 1b: Create a C++ wrapper . . . . . . . . . . . . . . . . . . . . 533.4.3 Step 2: Configure the configuration database . . . . . . . . . . . . . 56

3.5 Failure mechanisms with preparatory calculations . . . . . . . . . . . . . . . 593.6 Interface with the User Interface . . . . . . . . . . . . . . . . . . . . . . . . 60

3.6.1 Input from Ringtoets to Hydra-Ring . . . . . . . . . . . . . . . . . . 603.6.2 Input from other sources . . . . . . . . . . . . . . . . . . . . . . . 613.6.3 Output from Hydra-Ring to Ringtoets . . . . . . . . . . . . . . . . . 61

3.7 Aspects of malfunctioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Database design description 674.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 Design conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3 The project database (PD) . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.1 The field HydraulicModels . . . . . . . . . . . . . . . . . . . . . 694.3.2 The field Sections . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3.3 The field DesignTables . . . . . . . . . . . . . . . . . . . . . . . 704.3.4 The field Numerics . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.5 The field VariableDatas . . . . . . . . . . . . . . . . . . . . . . . 724.3.6 The field CalculationProfiles . . . . . . . . . . . . . . . . . . . 734.3.7 The field SectionFaultTreeModels . . . . . . . . . . . . . . . . . 744.3.8 The field SectionSubMechanismModels . . . . . . . . . . . . . . . 744.3.9 The field Fetches . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.10 The field AreaPoints . . . . . . . . . . . . . . . . . . . . . . . . 754.3.11 The field PresentationSections . . . . . . . . . . . . . . . . . . 754.3.12 The field Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.13 The field ForelandModels . . . . . . . . . . . . . . . . . . . . . . 754.3.14 The field Forelands . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.15 The field ProbabilityAlternatives . . . . . . . . . . . . . . . . 764.3.16 The field SetUpHeights . . . . . . . . . . . . . . . . . . . . . . . 764.3.17 The field CalcWindDirections . . . . . . . . . . . . . . . . . . . 764.3.18 The field Swells . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.19 The field WaveReductions . . . . . . . . . . . . . . . . . . . . . . 774.3.20 The field Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.21 The field Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.22 Output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.4 The configuration database (CD) . . . . . . . . . . . . . . . . . . . . . . . 784.4.1 The field Variables . . . . . . . . . . . . . . . . . . . . . . . . . 784.4.2 The fields MainMchanisms and Mechanisms . . . . . . . . . . . . . 784.4.3 The field SubMechanisms . . . . . . . . . . . . . . . . . . . . . . . 794.4.4 The fields SubMechanismModels and SubmechanismVariables . . . 794.4.5 The field FaultTree . . . . . . . . . . . . . . . . . . . . . . . . . 794.4.6 The fields FaultTreeModels and FaultTreeModelSubMechanisms . 804.4.7 The field PreparatorySubMechanisms . . . . . . . . . . . . . . . 80

4.5 The hydraulic load configuration database (HLCD) . . . . . . . . . . . . . . 814.5.1 The field LoadVariables . . . . . . . . . . . . . . . . . . . . . . . 814.5.2 The field Locations . . . . . . . . . . . . . . . . . . . . . . . . . 814.5.3 The fields RegionVariables and ResultVariables . . . . . . . . 814.5.4 The field Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.5.5 The fields Uncertainties and UncertaintyTypes . . . . . . . . . 82

4.6 The hydraulic results database (HRD) . . . . . . . . . . . . . . . . . . . . . 834.6.1 The field HRDLocations . . . . . . . . . . . . . . . . . . . . . . . 834.6.2 The field HRDResultVariables . . . . . . . . . . . . . . . . . . . 834.6.3 The field UncertaintyModelFactor . . . . . . . . . . . . . . . . . 84

iv Deltares

Contents

References 85

A Glossary of terms 87

B Database fields 91B.1 Fields in the project database (PD) . . . . . . . . . . . . . . . . . . . . . . 91B.2 Fields in the configuration database (CD) . . . . . . . . . . . . . . . . . . . 91B.3 Fields in the hydraulic location configuration database (HLCD) . . . . . . . . 92B.4 Fields in the hydraulic region databases (HRD) . . . . . . . . . . . . . . . . 92

C The collection of statistical data 95

D Class diagrams 99

Deltares v


vi Deltares

List of Figures

List of Figures

2.1 Conceptual sequence of the FBC-algorithm. . . . . . . . . . . . . . . . . . 62.2 Numerical time integration of discharge wave per tidal period. . . . . . . . . 72.3 Conceptual sequence of the NTI-algorithm. . . . . . . . . . . . . . . . . . 82.4 Arbitrary point in discharge wave, followed by upscaling . . . . . . . . . . . . 92.5 Conceptual sequence of the APT-algorithm. . . . . . . . . . . . . . . . . . 102.6 The evaluation of the limit state function. Left panel: the embedding of the

limit state function evaluation within the routine for the probabilistic technique.Right panel: the sequence of the evaluation itself. . . . . . . . . . . . . . . 12

2.7 Split the computation of the X variables into a strength and load part. . . . . 132.8 Conceptual sequence of the ring computation algorithm. . . . . . . . . . . . 182.9 The preprocessors are gathered in the Tools-part of the solution development

environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.10 Conceptual sequence of the closure scenarios algorithm. The codes between

brackets refer to the source code comments. . . . . . . . . . . . . . . . . . 212.11 Conceptual sequence of the closure scenarios combination algorithm. The

codes between brackets refer to the source code comments. . . . . . . . . . 242.12 Conceptual image that elucidates the concept of numerical integration of prob-

ability densities over the failure space, i.e. the space for which Z < 0, orequivalently H > h. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.13 Conceptual image of the result of the preprocessor for three wind speeds andtwo wind directions. The water level h (at an IMPLIC location) is visualizedon the vertical axis, whereas the return period, associated with the conditionalprobability, is visualized on the horizontal axis. . . . . . . . . . . . . . . . . 27

2.14 Example of the conditional Weibull distribution the model the water level atOS11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.15 Probabilities of different types of closure as function of the maximum waterlevel. The figure is taken from Rijkswaterstaat (2008). . . . . . . . . . . . . 34

2.16 The concept of parallellisation over multiple cores. . . . . . . . . . . . . . . 422.17 Implementation of the parallellisation through OpenMP within the FORM pro-

cedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.18 Implementation of the parallellisation through OpenMP within the Directional

Sampling procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1 Dependencies of Hydra-Ring on multiple modules. . . . . . . . . . . . . . . 463.2 Visualisation of the architecture of the WTI2017 software. Four parts are to

be discerned: a Hydra-Ring branch, a Ringtoets branch, a failure mechanismsbranch and a Delta Shell Light branch. . . . . . . . . . . . . . . . . . . . . 47

3.3 Create a new folder for the failure mechanism plugin. . . . . . . . . . . . . . 503.4 Create a new folder for the plugin and adapt the ‘General’ tab. . . . . . . . . 513.5 Create a new folder for the plugin and adapt the ‘Fortran-Libraries’ tab. . . . . 513.6 Create a new folder for the plugin and adapt the ‘Linker - General’ tab. . . . . 523.7 Check the boxes in the solution to assure the correct subversion properties. . 523.8 Create a new folder for the project. . . . . . . . . . . . . . . . . . . . . . . 533.9 Set the application settings by clicking the appropriate boxes. . . . . . . . . 543.10 Set the framework and references settings within the common properties. . . 543.11 Set the correct framework and references properties. . . . . . . . . . . . . . 553.12 Set the correct general configuration properties. . . . . . . . . . . . . . . . 553.13 Failure tree of the mechanism ‘structure failure due to overtopping/overflow’. . 563.14 The implementation algorithm for failure mechanisms running on prepatory

calls, as is the failure mechanism macrostability. . . . . . . . . . . . . . . . 59

Deltares vii


3.15 Data interface between Ringtoets and Hydra-Ring (the two blue boxes). Thered cylinders present databases of sqlite-type. The square gray boxes presentascii-type files. ‘PD’ stands for Project Database, ‘CD’ stands for Configura-tion Database, ‘HLCD’ stands for Hydraulic Load Configuration Database and‘HRD’ stands for Hydraulic Region Database. . . . . . . . . . . . . . . . . 61

3.16 Snapshot of an example ascii-type input log file. . . . . . . . . . . . . . . 623.17 Snapshot of an example ascii-type output log file. The red box depicts the

strength variable names (in either Dutch (language option NL) or English (lan-guage option UK). The blue boxes depicts names that are given in English.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.18 Snapshot of the logging of the design point for an example computation forovertopping/overflow for dykes. . . . . . . . . . . . . . . . . . . . . . . . . 64

3.19 Interface with error messaging components. . . . . . . . . . . . . . . . . . 65

4.1 Visualization of the datamodel from a dyke section perspective. . . . . . . . 684.2 Schematic image of the modification of data series in order to enforce mono-

tonicity of the data series. . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

C.1 List of spreadsheets that contain elementary information on basic random vari-ables associated with the water systems implemented in Hydra-Ring. . . . . 95

C.2 Example of a Microsoft Excel spreadsheet that is used to prescribe the basisstatistical information on each random load variable used in Hydra-Ring. Thistable displays the duration line for the discharge at Lobith. Notice the multipletab fields, with other input data. . . . . . . . . . . . . . . . . . . . . . . . 96

C.3 Automatic build of the HLCD database on the server. . . . . . . . . . . . . . 96C.4 List of the complete set of databases used by Hydra-Ring. On top: the HLCD-

database, the remainder of the list comprises hydraulic databases (HRD). . . 97

D.1 Class diagram for the functionality to combine the results over several failuremechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

D.2 Class diagram for the project database. . . . . . . . . . . . . . . . . . . . 100D.3 Class diagram for the numerical settings data fields. . . . . . . . . . . . . . 101D.4 Class diagram for wind-induced wave data. . . . . . . . . . . . . . . . . . . 102D.5 Class diagram for the variable data fields. . . . . . . . . . . . . . . . . . . 103

viii Deltares

List of Tables

List of Tables

2.1 Probabilities for different closure scenarios . . . . . . . . . . . . . . . . . . 33

A.1 Glossary of terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Deltares ix


x Deltares

1 Introduction

This document is entitled Technical Design of Hydra-Ring and forms the direct follow-up ofthe Functional Design (see Deltares (2016a)). In the Functional Design, the scope of theWTI2017-project has been described, making further recalling dispensable. This current doc-ument describes how the requirements from the Functional Design are realized in the soft-ware.

1.1 Background

In the Functional Design Deltares (2016a), the system requirements have been specified aswell as the software design and the internal and external interfaces of the software. The prin-ciple behind the contents of the Functional Design has been to identify the key componentsof the workflow to be supported by the software.

Since Hydra-Ring is a complex computational core with a profound scientific fundament, thesoftware components have an evident mathematical nature. The mathematical fundament iswritten down in Deltares (2016c). The two core elements of Hydra-Ring are:

� the execution of a failure probability computation as a reliability analysis of a single ele-ment, on a yearly basis,

� the combination of the results of this reliability analysis to a system of multiple elements,as well as for multiple failure mechanisms.

Another relevant principle has been to divide these components into software componentshaving a single responsibility and performing a job with the least side effects for other com-ponents. This current document can be perceived of as the technical continuation of theFunctional Design by means of systems design. Systems design is the process of definingthe architecture, components, modules, interfaces, and data for a system to satisfy specifiedrequirements, including aspects of modularity.

1.2 Purpose and scope of this document

The purpose of this Technical Design is to provide the technical specifications of Hydra-Ringregarding the following three aspects, namely the system design, the interface design and thedatabase design.

The system design consists of three parts, namely the failure probability computation rou-tines, the combination routines and some preprocessor tools. The failure probability routinesstart from the framework of time integration routines (FBC, NTI and APT). Regarding thepreprocessor, the scope of the system design description is limited to the closure regimespreprocessor, the Easternscheldt preprocessor and the wind direction switch preprocessor.

The description of the interface design is focussed on the connections with the failure mech-anisms and the general core libraries. The latter category is set apart from the computationalkernel in order to assure the modularity of the system, thus minimizing the chance of sideeffects among components.

The scope of the database design description compasses the four elementary databaseHydra-Ring runs on, namely the Project Database (PD), the Configuration Database (CD), theHydraulic Load Configuration Database (HLCD) and the Hydraulic Region Database (HRD).Note that the HLCD and HRD are not adaptable by the user. On the contrary, the PD is pre-eminently subject to the user’s input wishes. The CD is actually only to be used by advancedusers and programmers.

Deltares 1 of 106


1.3 Version

The present document is associated with the software delivery of Hydra-Ring by September1st, 2016, i.e. version Hydra-Ring 2.0. The present document heavily relies on the De-sign Document Markus et al. (2011)). The Design Document was written by Arjen Markus(Deltares), Henri Steenbergen (TNO) and Rob Brinkman (Deltares) and reviewed by MarcelVisschedijk (Deltares), and is the follow-up of the initial definition study by Visschedijk (2010).Discussions and approval have been recorded in two memoranda (see Deltares (2011)). Theassociated counterpart from Rijkswaterstaat WVL has been Robert Slomp.

In this document, revisions have been applied to mutually align the document with the state ofthe software. Moreover, the document is modified in order to meet the document standards asagreed upon by Deltares and Rijkswaterstaat, through the persons Louis Verhagen (Deltares),Hans van Putten (Deltares) and Hillie Wams (Rijkswaterstaat CIV). The actual modificationshave been carried out in 2016 by Wim van Balen (Deltares), Tom The (Deltares) and KarolinaWojciechowska (HKV). These modifications have been gathered in version 1.9; later in 2016,Guus Rongen (HKV) has added background descriptions on the Easternscheldt preprocessor,resulting in a version 2.0. Due to some changes in December 2016 this document has beenupdated.

This Technical Design is closely related to the other documents on Hydra-Ring:

1 Functional Design (Deltares (2016a)): functional backgrounds and requirements,2 Technical Design (Deltares (2016b)): this document,3 Technical Reference Manual (Deltares (2016c)): scientific backgrounds of Hydra-Ring,4 Test Plan (Deltares (2016d)): the philosophy behind the test procedures for Hydra-Ring,5 Validation Document (Deltares (2016e)): the results of the test procedures.

All these documents are written in English.

1.4 Outline

This Technical Design consists of three parts. First, the system design is described in chap-ter 2; this chapter is closely related to the functionality required as written down in the Func-tional Design Deltares (2016a). Second, the interface design is described in chapter 3; in thischapter, the interface of the computational core Hydra-Ring with other components, such aslibraries and distinct failure mechanisms, is described. Third, the four databases on whichHydra-Ring strongly relies on are specified in chapter 4. The four databases comprise theProject Database (PD), the Configuration Database (CD), the Hydraulic Load ConfigurationDatabase (HLCD) and the Hydraulic Region Database (HRD).

Four chapters have been appended to the document. General nomenclature is gathered in adedicated appendix: Appendix A. The full list of databases content is provided in Appendix B.The treatment of the statistical data for the hydraulic load for each region is illustrated inAppendix C. Some class diagrams are shown in Appendix D.

2 of 106 Deltares

2 System design description

In this chapter, the system components are described subsequently. Whereas the scientificbackgrounds of the system components are described in Deltares (2016c) and the functionalrequirements are written down in Deltares (2016a), the current chapter focuses on the tech-nical backgrounds of the system components.

2.1 System components

The Hydra-Ring software contains the following two core functional components:

� Functionality for failure mechanisms: the execution of a failure probability computation asa reliability analysis of a single element, on a yearly basis. This component is treated insection 2.2.

� Functionality for combining failure probability contributions: the combination of the resultsof this reliability analysis to a system of multiple elements, as well as for multiple failuremechanisms. This component is treated in section 2.3.

In addition to these two core components, multiple preprocessors have been built to supportspecific functional elements. These preprocessors, being components outside Hydra-Ring,are treated in section 2.4. Some non-functional components are depicted in section 2.5.

2.2 Functionality for failure mechanisms

The core of Hydra-Ring determines the failure probability for a subsection (i.e. a dike section,or the part of a dike section that lies entirely within a presentation section), per mechanism,per revetment layer and per subsoil scenario (alternative). This result, together with someadditional information, is written to the results database for further processing.

Failure probabilities in Hydra-Ring are first computed for relatively small time scales in whichthe temporal variation of the relevant hydraulic variables (water level, wind etc) is small enoughto be assumed constant. This time scale is referred to as the basic time scale, for instanceequal to a tidal period (12 hours and 25 minutes). Output failure probabilities are generallyexpressed per year, which means that the failure probabilities of the basic time scale need tobe upscaled to an annual failure probability.

For this purpose, the following three alternative upscaling methods are available to calcu-late these failure probability (FP) contributions (see Deltares (2016c) for the scientific back-grounds): Three alternative time integration schemes are available to calculate these failureprobability (FP) contributions (see Deltares (2016c) for the scientific backgrounds):

� the Ferry Borges Castanheta scheme, abbreviated as FBC,� the Numerical Time Integration scheme, abbreviated as NTI,� the Arbitrary Point in Time scheme, abbreviated as APT.

The user can select which method is to be used. The choice of the method determines theorder in which the subroutines are executed. The loop sequence of these different methodswill be presented hereafter in a Program Structure Diagram (PSD): in section 2.2.1 for FBC,in section 2.2.2 for NTI and in section 2.2.3 for APT.

Deltares 3 of 106


2.2.1 Calculation scheme Ferry Borghes Castanheta (FBC)

The FBC improved method is comparable to the method used by PC-Ring. It assumes a blockshaped discharge wave. Therefore iterations are required to match the duration of the blockperiod with the annual statistics of the most slowly evolving variable (discharge or lake level).Compared to the method in PC-Ring, the loops for the wind and the closing situations havechanged, in order to improve accuracy. The algorithm is elaborated below:

Wind-direction loopClosing situations loop (6)

Initialise block duration per wind directionBlock duration iteration (3)

Sub-mechanism loop- Compute failure probability (FP) of sub-mechanism per tidal period (1)

Sub-mechanism loop end- Combine sub mechanisms (2)- Compute new block duration per wind direction (3)

Block duration iteration end (3)Compute FP again with final block duration

Closing situations loop end (6)- Upscale to the longest block duration (over all closure scenarios) foreach random load variable (7)

- Combine FP for closing scenarios (8)- Upscale from cross section to dike segment (4)- Process probability of wind direction (5)

Wind-direction loop end- Upscale to the longest block duration (over all wind directions) foreach random load variable (9)

- Combine FP over wind directions to derive omni-directional FP (10)- Incorporate the wind direction as a random variable- Upscale FP to annual failure probability (11) (assuming uncorrelated peak

values of discharge waves)- Store FP for selected dike segment and mechanism

The numbered statements in the FBC method PSD can be elaborated as follows and visual-ized in Figure 2.1:

1 Determine the failure probability per sub-mechanism. Input are the block duration perstochastic variable and the wind direction. In the calculation, the statistics of all randomvariables are scaled according to their respective block durations (which can differ perwind direction and closure scenario).

2 Combine the failure probabilities of the sub-mechanisms to one failure probability permechanism. Input are the block duration per stochastic variable and the wind directionfor each cross section.

3 Loop block duration. Compute a new value for the block duration for all stochastic vari-ables based on the computed value of each random variable in the design point. Thesedurations are derived from available duration curves (input of Hydra-Ring) that describethe relation between the values of (slowly varying) random variables and the average du-ration of exceedance. Steps 1-3 are repeated a number of times until the values of theblock durations have converged.

4 Upscale failure probability of a cross section to a dike sectionInput are block durationper stochastic variable and wind direction.The calculation is made for the smallest block-duration over all stochastic variables (usually the tidal scale).

5 Combine the failure probability for each wind direction with the probability of occurrenceof that wind direction.

6 Closing situation loop. Process the different situations for different states of a closablestorm surge barrier (open and closed).

4 of 106 Deltares

System design description

7 Upscale to the longest block duration (over all closure scenarios) for each random loadvariable. In order to combine failure probabilities over closure scenarios (in step 8), theblock duration for a load variable needs to be the same over all closure scenarios. There-fore, for each closure scenario wind direction, the failure probability is upscaled to themaximum block duration over all closure scenarios. This process is executed separatelyfor each load variable, and the temporal autocorrelation of the other load variables are setequal to 1.

8 Combine closure scenarios, taking into account the failure probability of the closure situa-tions, as well as the probability that the closing criterion is met.

9 Upscale to the longest block duration (over all wind directions) for each random load vari-able. This step is similar to step 7 for the closing scenarios

10 Combine the failure probability per wind direction to an omni-direction failure probability.The input is the block duration per stochastic variable.

11 Upscale the failure probabilities to a year. This upscaling is done step by step: from thesmallest block duration to the second smallest, then to the third smallest etc until thelargest block duration. The final step is the upscaling from the largest block duration to ayear.

The scientific motivation for the specific numerical choices implicated by the approach de-scribed above, is provided in Deltares (2016c).

Deltares 5 of 106


Figure 2.1: Conceptual sequence of the FBC-algorithm.

6 of 106 Deltares


2.2.2 Calculation scheme Numerical Time Integration (NTI)

The NTI method is new functionality compared to the software package PC-Ring. The methodis comparable to the time integration routines as implemented in the Hydra-modules. The keyelement of this method is that the discharge wave is directly integrated numerically. The NTI-concept is briefly conceptually recapitulated in Figure 2.2.

Figure 2.2: Numerical time integration of discharge wave per tidal period.

The algorithm is elaborated below, and visualized in Figure 2.3:

Tidal period loopWind-direction loop

Closing situations loopSub-mechanism loop

- Compute FP of sub-mechanism per tidal periodSub-mechanism loop end- Combine submechanisms

Closing situations loop end- Combine FP for closing scenarios- Upscale from cross section to dike segment- Process probability of wind directionWind-direction loop end- Combine FP over wind directions to derive omni-directional FP- Incorporate the wind direction as a random variable

Tidal period loop end- Combine the FP of the tidal elements to derive the discharge wave FP- Upscale FP to annual failure probability- Store FP for selected dike segment and mechanism

Compared to FBC, the following items are different:

� Inside the procedure to determine the failure probability per tidal period, the stochasticvalue of the discharge is scaled per time increment, with the help of a fraction parameter. Atrapezoidally shaped temporal evolution of the discharge is assumed, with the top durationa function of the peak value. The sum of the time increments equals the discharge wave.

� The contributions of the different tidal periods need to be integrated in time with a combi-nation procedure.

� The peak discharge is constant for all time steps.


Deltares 7 of 106


Figure 2.3: Conceptual sequence of the NTI-algorithm.

8 of 106 Deltares


2.2.3 Calculation scheme Arbitrary Point in Time (APT)

The APT method is new functionality compared to both the software package PC-Ring andthe Hydra-modules. The key element of this method is that the block duration is treated as arandom variable. A dedicated time integration loop is hence not necessary. The NTI-conceptis briefly conceptually recapitulated in Figure 2.4.

Figure 2.4: Arbitrary point in discharge wave, followed by upscaling

The algorithm is elaborated below, and visualized in Figure 2.5:

Wind-direction loopClosing situations loop

Sub-mechanism loop- Compute FP of sub-mechanism per tidal period

Sub-mechanism loop end- Combine partial mechanisms

Closing situations loop end- Combine FP for closing scenarios- Upscale from cross section to dike segment- Process probability of wind direction

Wind-direction loop end- Combine FP over wind directions to derive omni-directional FP- Incorporate the wind direction as a random variable- Upscale from tidal period to discharge wave- Upscale to annual failure probability- Store FP for selected dike segment and mechanism

Compared to FBC, the size of the discharge value in a discharge wave is now scaled with thehelp of an additional random fraction parameter f . Doing this, the block duration iteration inFBC is not required.


Deltares 9 of 106


Figure 2.5: Conceptual sequence of the APT-algorithm.

10 of 106 Deltares


2.2.4 Compute the failure probability of a submechanism

The core of each of the three computation schemes (FBC, APT and NTI) is the calculationof the failure probability (FP) of a submechanism per cross section. This is the probabilitycomputation of single elements as described in Deltares (2016c). This module calls one ofthe probabilistic methods (e.g. FORM, Directional Sampling, etc.), which then calls repetitivelythe appropriate limit state function of the submechanism.

Hydra-Ring supports a number of different probabilistic methods (req. [FR3]). All individualprobabilistic methods have the same interface and all return the result in the same way::

� a vector αi with length i, where i is the number of random variables. This vector isnormalized, i.e. the sum of the squares of the individual components of αi is equal to 1(see Deltares (2016c)),

� a value β representing the distance of the design point to the origin in standard normalizedspace, which is a measure for the failure probability Pf via Pf = Φ(−β) (see Deltares(2016c)).

In principe, all methods can be used in combination with any failure mechanism and location,irrespective of the precise properties. The subroutine calculateSubMechanism takes allinput data that are required and passes them on to the selected probabilistic method, assketched below:

subroutine calculateSubMechanism( probDb, zfunc, method, alpha, beta,pf, design, conv )

... Declarations

... Preliminariesselect ( method )

case( ''FORM'' )call performFORM( probDb, zfunc, ... )

case( ''DIRS'' )call performDirectionalSampling( probDb, zfunc, ... )

case( ... )... other methods

end select... Store the design point (in direction vector alpha and length beta)... Report the result if needed

end subroutine

In the above code, zfunc is the limit state function (often simply referred to as the Z-function)of the submechanism. Its return value indicates whether the dike/hydraulic structure will failunder the given hydraulic load (water level and waves). This is the case if the Z-function hasa negative value. All Z-functions have the same interface.

As soon as the user has chosen for a certain computational method, e.g. FORM throughperformFORM, then the software starts evaluating the limit state function in an iterative way.For each sample, the limit state function is evaluated. In case of FORM, an initialisation of thestarting vector is necessary. For this starting vector, several starting methods are available(see Deltares (2016c)). The conceptual sequence for FORM is shown in Figure 2.6.

The core of the evaluation is the routine zrFunc: within this routine, the actual limit statefunction is evaluated. This step comprises three substeps:

1 the statistics are set within routine calculateHydraulicStat: this subroutine transformsthe vector U of independent (uncorrelated) normal stochastic load parameters to corre-

Deltares 11 of 106


Figure 2.6: The evaluation of the limit state function. Left panel: the embedding of thelimit state function evaluation within the routine for the probabilistic technique.Right panel: the sequence of the evaluation itself.

lated physically meaningful parameters X , at the position of relevant output locations ofthe HRD database,

2 the load part is carried out within routine calculateHydraulicLoad: this subroutinecalculates the required hydraulic load values at the toe of the dike, using the physical loadparameters at the output locations; the influence of a foreshore is included in these steps,

3 the strength part is dealt with within routine calculateZFunction, for instance by eval-uating the actual Sellmeijer formula, in case of piping. The setup shown in Figure 2.6 isgeneralized in order to be compatible with any conceivable failure mechanism.

2.2.5 Time scales and temporal evolution of load variables

The time scale of a hydraulic load variable is the time at which the autocorrelation function ofthis variable reaches zero. For example, for a discharge wave, the time scale may be on theorder of several weeks. Each discharge wave is independent of the wave that preceded it (nocorrelation). The number of time scales in a computation according to the FBC, APT or NTIprocedure will depend on the number of unique time scales of the load variables.

Examples of load variables with different time scales are: wind speed, sea water level andwave height with a time scale on the order of a tidal period, discharge and lake level with atime scale on the order of weeks, precipitation with a time scale on the order of hours or days.

In Hydra-Ring, there is currently only the capacity to take into account one slowly-evolvingvariable (the variable with the largest time scale). In the Dutch situation, these are the riverdischarges or the lake levels. The temporal evolution of this variable is represented as a block(FBC model), or as a trapezoid (NTI model, APT model).

To keep the model flexible, a number of time scales may exist with a time scale smaller thanthe slowly-evolving variable. A generalized procedure for temporal upscaling facilitates theiterative upscaling for different groups of variables, each with a different time scale.

12 of 106 Deltares


2.2.6 Parameter distributions and correlations

The definition of the strength variables per failure mechanism is performed in the configura-tion database (CD, see section 4.4). The definition of the associated distribution functionsand parameters is performed via the general Project database (PD, see section 4.3). Thedefinition of the load variables and associated distribution and (bivariate) correlation functionsplus parameters is performed per version, via a hydraulic location and configuration database(HLCD, see section 4.5). The documentation Deltares (2016c) contains an overview of allsupported distribution functions and correlation functions for strength and loading variables.

Strength variables are assumed to be mutually uncorrelated1, whereas load variables can bemutually correlated. Consider, for example, the following variables: water level at sea h, windvelocity U10 and wind direction θ as well as significant wave height Hs, then:

� the water level at sea is considered an independent variable,� the wind velocity is considered to be correlated to the water level at sea, with coefficients

that depend on the wind direction,� the wave height is correlated to the wind velocity.

Another difference between strength and load variables is that the probability distributions ofstrength variables are generally described by a set of ‘standard’ functions such as normal,lognormal etc, whereas for load variables sometimes very specific distribution functions areused. Hydra-Ring therefore applies a different approach for strength and load variables, asdescribed below.

Figure 2.7: Split the computation of the X variables into a strength and load part.

Hydra-Ring processes the different types of stochastic load variables in the following order (cf.Figure 2.7):

1Extension to mutually correlated strength variables is possible in future; by transforming the strength part ofthe U -vector with the help of a Cholesky decomposition of the correlation matrix.

Deltares 13 of 106


� Independent load variables, for these parameters, Hydra-Ring applies the associatedprobabilistic distribution directly.

� Partly correlated variables, such as the discharge of the river Meuse, which is correlatedto that of the Rhine. The value of such a variable is described as a function of an indepen-dent part and a part that depends on another load variable via a correlation model. ThecalculateHydraulicStat routine supports two classes of correlation models. The firsttype correlates two values of normally distributed U -components. The second type cor-relates the values of two physical X-components directly. Hydra-Ring assumes that theorder of taking into account the correlations between different load variables is determinedby the order in which they appear in the vector of physical load variables (X). Thereforeone needs to define the “most independent” variables first, and then the “more and moredependent” ones.

� Fully correlated variables, such as the discharge of the Meuse at Borgharen, which is fullycorrelated to the discharge at Lith. In this case the U -components of the two variablesare identical, even though the physical parameters are not. By referring to the same U -variable, no correlation model is required.

� Fractions are special parameters that are used in the APT and NTI methods to representthe value of the river discharge as a percentage of the peak. These fractions are a functionof the time of occurrence within the flood wave.

2.2.7 Hydrodynamic models

Combinations of samples of load variables can be considered as synthetic events that maylead to failure of the flood defence system. For each event the resulting hydraulic load at theflood defences (water levels, waves) needs to be derived, in order to provide an estimate ofthe failure probability. This is generally achieved by executing a large number of hydrodynamicmodel simulations. The results of the model simulations are stored in the input databases ofHydra-Ring.

2.2.8 Wave generation, load transformation and load model uncertainty

The hydrodynamic models as mentioned in the previous section generally produce water lev-els and wave conditions at locations at some distance from the toe of the flood defence.In some applications, additional models are required to translate conditions from the modeloutput locations to the toe of the flood defence. Hydra-Ring contains various methods andmodels for this purpose. A number of practical issues need to be tackled. For instance, theoutput locations of wave models and water level models may not coincide.

In non-coastal areas, water levels are computed at their user selected output locations (nearbythe flood defence section location), through spatial interpolation of the available water levelsfrom the hydrodynamic database (HRD, see section 4.6). In coastal areas, wave parametersare usually available at densely distributed output locations along the shore. The water lev-els at these locations are derived by spatial interpolation from the available statistics at a setof measurement stations. For this purpose a triangular interpolation method is applied, i.e.interpolation between water levels of three ‘nearby’ water level stations. The selection proce-dure of the water level stations is a preprocessing step, so the input database of Hydra-Ringcontains the ID’s for the three water level stations for each output location of the wave model.

Below follows an overview of the sequence in which Hydra-Ring currently applies methods toderive the load at the toe of the flood defence.

1 If required: apply water level corrections (the so-called MHW corrections). These correc-tions guarantee that the water level for the normative frequency is equal to the normativewater level, which is derived with other software packages in a slightly different way. The

14 of 106 Deltares


corrections will be defined in the HRD database as much as possible.2 For given realisations of random load variables like water level, wind speed and wind

direction, derive the associated wave characteristics through interpolation in tables fromthe hydrodynamic database (i.e. interpolation over the water level, the wind speed and thewind direction).

3 Compute the water level at the flood defence thorugh spatial interpolation between outputlocations of the hydrodynamic model. Apply the same procedure for the wave parameters,when available.

4 In case hydraulic model uncertainties are taken into account, add the stochastic modelerror to the local water level. The distribution parameters for model uncertainty are definedin the HLCD database.

5 Add an optional user-defined wind setup for the water level at the output locations, perwind direction.

6 In case the wind-induced wave parameters are not available from the HRD database:calculate the wave parameters with the Bretschneider formula. The Bretschneider param-eters are defined in the project database (PD). For the new HRD-database for WTI2017,the results of Bretschneider computations are directly put into the HRD.

7 Correct the wind-induced wave parameters for the influence of swell. If swell parametersare not available in the HRD database, then they can alternatively be user-defined.

8 Apply an optional wave reduction via a simple breakwater model (with support for user-defined rubble mound, caisson or vertical wall types), or via direct user input of a wavereduction factor.

9 Modify the water level and waves due to the influence of a foreland with either a simpletoe reduction or with the foreland module that is incorporated in Hydra-Ring.

10 Apply the stochastic model uncertainty for the wave direction by summation.

2.3 Functionality for combining failure probability contributions

The description, up to this point, has described the reliability analysis for a single element. Inorder to combine these individual results, the strategy as described in this section is neces-sary. The scientific motivation for the specific numerical choices implicated by the approachesdescribed in this section, is provided in Deltares (2016c).

2.3.1 Calculation scheme

Once the results are available for a number of subsections and failure mechanisms, the prob-abilities will be combined, in order to find an overall probability per presentation section and anoverall probability for dike rings, i.e. a combination of presentation sections. This combinationruns over all selected mechanisms, sections, revetment layers and subsoil scenarios.

This combination needs to be done by taking correlations between failure mechanisms anddike sections into account. This correlation is modelled by assuming a correlation functionwithin the section and a residual correlation between adjacent sections. The combined failureprobability of two mechanism is determined, schematically, using the formula below:

P (A ∪B) = P (A) + P (B)− P (A ∩B) (2.1)

= P (A) + P (B)− P (A) ·P (B|A) (2.2)

in which ∪ denotes an OR-gate and ∩ an AND-gate, and where P (A) is the failure dueto mechanism A and P (B) the failure due to mechanism B. The conditional probabilityP (B|A) is computed with the Hohenbichler method. This method uses linearised descrip-tions of failure mechanisms. The linearised function are simplifications and as such an error isintroduced. To minimize the error, the mechanisms are combined in an order that is based onmutual correlation. So first the two mechanisms are combined that are correlated strongest,

Deltares 15 of 106


then the two mechanisms that are correlated ‘second strongest’ and so on. This ensures thatthe correlation information is processed as accurately as possible.

More in detail:

For each (sub)section:[1] Combine a number of subsoil scenarios per mechanism layer to one single failure

probability by using the probabilities for each scenario. This step is done totake into account the uncertainty in the subsoil characteristics. This step isonly required for mechanisms for which the subsoil is relevant.

[2] Combine the layers that are distinguished per mechanism to one single failureprobability. (If there is only one layer, this step is trivial).

[3] Combine the individual submechanisms for this main failure mechanism.

and then:

At the end of step 3 we have a failure probability for one (sub)section and onemain mechanism. We can now continue the aggregation to the presentation sectionor the entire dike ring:[4] Combine the (sub)sections that are part of one presentation section, to obtain

one failure probability for each mechanism that is relevant for thepresentation section.

[5] Combine the results of step 4 over all mechanisms.[6] Combine the dike/presentation sections, to obtain one failure probability

for the whole dike ring.This is the final result of Hydra-Ring: the failure probability for a dike,dike section or entire dike ring, based on the selected failure mechanisms.

Note is that in the above description of the combination procedure the term “combine” is notalways carried out by the same routines, due to the different types of correlations that areinvolved.

2.3.2 On the length of a section

Hydra-Ring uses sections as computational units. A section represents a stretch of dike ordune with statistically homogeneous strength properties and with statistically homogeneoushydraulic loads. It is increasingly common for local water authorities in The Netherlands todefine small sections, due to the increased availability of measurements with high spatialdensities. The drawback, as far as Hydra-Ring is concerned, is that spatial correlation modelof Hydra-Ring should not be applied on dike sections that are “too small”.

This model assumes that two dike sections are only weakly correlated, that is via the residualcorrelation only (cf. Deltares (2016c) for an explanation on the residual correlation). Within adike section the correlation is assumed to be higher. Consequently, if a dike section is split upinto smaller parts, the computed combined failure probability of the entire dike section will behigher than for the situation in which a dike section is considered as a whole.

FR12 already states that this issue will not be solved in Hydra-Ring. The reason is that thiswould require a different correlation model and this would result in a complete new set-upof the program that might take years of research. It was therefore decided to introduce amimimum allowed length for a dike section and to provide a warning to the user if smallersections are used.

16 of 106 Deltares


2.3.3 Ring computation

The ring computation program is used to combine failure probabilities to an over all failureprobability. The mechanism computation program delivers design points (β and a set of αi)for a specific section, mechanism, alternative and layer. The goal of the ring computation isto combine the available design points to a final ring failure probability and ring design point,and to log all intermediate steps.

The order of combining design points is as visualized in Figure 2.8 (recall the visualizationof the datamodel from a dyke section perspective from Deltares (2016a), also visualized inFigure 4.1). Hydra-Ring supports the ring computation for a dyke stretch that is threatened byone, and only one, water system. Thus, spatial correlations between water systems are notsupported.

In diagram Figure 2.8 it can be seen that the starting point is a set of design points, definedfor an alternative, layer, section, mechanism, which implicitly define the main mechanismand main mechanism. The first combination action compiles the alternatives (piping) and thesecond combination action compiles the layers (revetments).

The failure probability is defined as a reliability index β and a set of αi for each mechanism,section, alternative, layer and presentation section, so we get the following structure in theFortran program and in the database (field – type):

� Ring combination method – Indication whether main mechanisms are rolled up first orpresentation sections.

� Presentation – Key.� Main mechanism – Key.� Main mechanism combination method – Indication whether mechanisms are rolled up

first or sections.� Mechanism – Key.� Section – Key.� Layer – Key.� Alternative – Key.� Beta – Value.� Alpha – Array of values.� First parent design point – Indication of the design point to which this design point

contributes.� Second parent design point – Indication of another design point to which this design

point contributes.

In the Fortran data structure the parents comprise a list of children. However, the informationis the same. A special meaning is given to the key (key value – meaning):

� larger than 0 – References a specific alternative, layer, section, mechanism or presenta-tion section.

� 0 – Indicates a combined result.� -1 – Indicates an invalid combined result, which must be updated by the ring computation

application.

Hydra-Ring calculates the reliability index β and α-values for a specific alternative, layer,section and mechanism. These values are written into the database. They also belong to apresentation section, because each section belongs to a presentation section.

When writing new values in the database, combinations based on these values are not valid

Deltares 17 of 106


Figure 2.8: Conceptual sequence of the ring computation algorithm.

any more. Therefore these data will be removed. This is a cascading delete, so all combina-tions based on combinations are removed too.

Then records are inserted for all combinations to be performed. This means that if the mech-anism calculation delivers one deisgn point, 12 design points are inserted. From these designpoints 11 design points have a -1 key on some level, indicating that the design points are notup-to-date and should be calculated by the ring calculation.

18 of 106 Deltares


The combination program reads results data and generates combined results. This is done inthe order described above. If there is only one contributor to a combination, the combinationresult is equal to the contributor result. If there are no contributors, the combined record willbe deleted from the database. This situation cannot happen in normal usage of Hydra-Ringand Combin, but could happen if section or mechanisms records are deleted manually fromthe database. Once deleted, they do not contribute anymore to combinations on a higherlevel.

All combinations are performed in the same way. In a set of results, results are combinedone by one, starting with the largest values. This will be done by the subroutine namedcombineArrayElementsPartialCorrelation, which calls internally the subroutine namedcombineTwoElementsPartialCorrelation, which takes care of combining two results.The latter method performs a Hohenbichler calculation, which runs on a FORM calculationto combine two results.

As input for the Hohenbichler method, two sets of the reliability index β andα-values are used.Besides that, the ρ-value per stochastic variable is used. This value is needed to compute thecorrelation between the two sets by expressions written down in Deltares (2016c).

This method applies for all combinations, so for layers, sections, mechanisms and presenta-tion mechanisms. Only in the case of alternatives there is an additional step to take, becausealternatives represent different sub soil models which have a probability of occurrence of theirown. This probability is regarded as uncorrelated with the failure probability. Therefore beforeapplying the algorithm described above, the failure probability is combined (multiplied) withthe sub soil probability of occurrence. Then the usual steps are taken.

2.4 Preprocessors

In order to benefit the performance of Hydra-Ring, some operations are set apart outsidethe software. In this sections, such preprocessors are described functionally as well as theirrelation to the core components of the Hydra-Ring software. Four preprocessors are dis-cussed: the one for closure scenarios (in section 2.4.1), the one for the Easternscheldt (insection 2.4.2), the one for dunes (in section 2.4.3) and the one for switching off winds (insection 2.4.4). The preprocessors are gathered in the Tools-part of the solution developmentenvironment, see Figure 2.9.

2.4.1 Closure scenarios

A special part of the computational procedures is the treatment of the so-called closure sce-narios, which are related to different states of closable storm surge barriers. For example, thedownstream Rhine and Meuse area near Rotterdam and Dordrecht is protected by the Maes-lant barrier. This structure should be closed when the expected water levels at Rotterdamor Dordrecht exceed certain thresholds. The actual closing situation may be in a conflict-ing state, due to failure in the electrical system for instance. The complete failure probabilitydetermination of a dike section therefore has to consider the following scenarios:

� The barrier operates according to expectation and the water level remains below the clo-sure criterion. Therefore the barrier is open.

� The barrier operates according to expectation and the water level exceeds the closurecriterion. Therefore the barrier is closed.

� The barrier does not operate according to expectation and the water level does not exceedthe closure criterion. Therefore the barrier is closed.

� The barrier does not operate according to expectation and the water level exceeds theclosure criterion. Therefore the barrier is open.

Deltares 19 of 106


Figure 2.9: The preprocessors are gathered in the Tools-part of the solution develop-ment environment.

Details on the computation procedure for these scenarios are given in section 2.5 of the scien-tific documentation. The computation method uses linearisations of Z-functions and thereforerelies on the assumption that the error introduced by the linearisation is small. Unfortunately,this turned out not to be the case for the closure scenarios. The linearisation of the limit statefunction that represents the closure criterion introduces an error, caused by one variable inparticular: water level prediction error ε.

To solve this problem, this variable is dealt with through numerical integration. In the numericalintegration approach, a numerical grid is defined to represent the domain of outcomes of ε.For each value of ε, the probability of failure, given ε is calculated. In order to do so, alinearised limit state function is required for each value of ε. To reduce computation time, thelinearization is executed only once, as preprocessing action.

In the preprocessing, Hydra-Ring needs to be run in a special mode for the situation of anopen barrier in order to find the design point at which the closure criterion is exceeded. Thisneeds to be done for each calculation scheme (FBC, APT, NTI), each wind direction and eachgrid value of ε separately. Note that this is only possible if the hydrodynamic data for openand closed barriers are available. The resulting design points are added to the input databasefor Hydra-Ring. The overview of the workflow of the pre-processor module, including the write

20 of 106 Deltares


routine is given in the diagram as visualized in Figure 2.10 (codes between brackets refer tothe source code comments).

Figure 2.10: Conceptual sequence of the closure scenarios algorithm. The codes be-tween brackets refer to the source code comments.

In reality, it is possible that more than one barrier protect a certain region. Currently, Hydra-Ring is not able to cope with such systems, but this is one of the possible additional featuresin the near future. The pre-processor module for the closure scenarios is implemented as aspecial case (method 5) of the design table computation (method 3, see section 4.3.3). Thereare four main differences:

Deltares 21 of 106


1 A single closing situation is computed in the design table computation, since only the opensituation is of importance for the computation of a closure criterion. This is also done byaltering the number of situations after reading the database input [PCC3/PCC5].

2 The design parameter is treated as a deterministic variable, irrespective of the input dis-tribution. This is done by altering the variable definitions after reading the database inputand restoring them after the design table computation is finished [PCC2].

3 The calculation scheme routines (FBC, APT and NTI) store computed design points perwind direction additional to the final design points [saveCSP].

4 Results are written to the HRD database [PCC6].

The collection of design points for each combination of an item in the design table and winddirection is written to the HRD database by a separate routine. This routine compares theresults to existing results in the database. Only results that have smaller β-values than existin the database (i.e. are normative) are actually written to the database. Due to this compar-ison it is possible to define closure criteria based on multiple characteristics, for example onmultiple locations [PCC6].

The preprocessor module is, like a normal design table computation, configured through theproject database. In the project database a calculation scheme (FBC, APT and NTI) is se-lected. In order to obtain a full input database, the pre-processor needs to be run for eachcalculation scheme. Also the definitions of the closure criteria (e.g. critical water levels) arestored in the project database as follows (see section 4.3 for explanation of the labels):

DELETE FROM [Areas];INSERT INTO [Areas] VALUES (1, '1', 'Nederland');

DELETE FROM [Projects];INSERT INTO [Projects] VALUES (1, 'Sprint', 'Hydra-Ring Sprint');

DELETE FROM [AreaPoints];DELETE FROM [PresentationSections];

DELETE FROM [Sections];INSERT INTO [Sections] VALUES ( 1, 1, 1, 'Rotterdam', 'Rotterdam (region 3)', ...

94440, 436924, 94440, 436923, 308071, 308071, 100, 210, 1);INSERT INTO [Sections] VALUES ( 2, 1, 1, 'Dordrecht', 'Dordrecht (region 4)', ...

105822, 426052, 105821, 426052, 308121, 308121, 100, 45, 1);

DELETE FROM [Profiles];DELETE FROM [CalculationProfiles];DELETE FROM [Forelands];

DELETE FROM [HydraulicModels];INSERT INTO [HydraulicModels] VALUES (1, 0, 'WTI 2017');

DELETE FROM [ProbabilityAlternatives];DELETE FROM [SectionFaultTreeModels];INSERT INTO [SectionFaultTreeModels] VALUES (1, 1, 1, 1, 1);INSERT INTO [SectionFaultTreeModels] VALUES (2, 1, 1, 1, 1);

DELETE FROM [Numerics];INSERT INTO [Numerics] VALUES ( 1, 1, 1, 1, 1, 12, 4, 50, 0.15, 0.005, ...

0.05, 0.005, 2, 1, 10000, 20000, 0.1, -6, 6, 25 );INSERT INTO [Numerics] VALUES ( 2, 1, 1, 1, 1, 12, 4, 50, 0.15, 0.005, ...

0.05, 0.005, 2, 1, 10000, 20000, 0.1, -6, 6, 25 );

DELETE FROM [DesignTables];INSERT INTO [DesignTables] VALUES ( 1, 1, 1, 1, 5, NULL, 48, -1.05, ...

0.45, 0.05, 2.0, 5.0, 3.156179 );

22 of 106 Deltares


INSERT INTO [DesignTables] VALUES ( 2, 1, 1, 1, 5, NULL, 48, -1.05, ...0.45, 0.05, 2.0, 5.0, 3.156179 );

DELETE FROM [VariableDatas] ;INSERT INTO [VariableDatas] VALUES ( 1, 1, 1, 1, 26, 3.0, 0, 0.0, 0.0, ...

NULL, NULL, 0, 0.10, 300 );INSERT INTO [VariableDatas] VALUES ( 2, 1, 1, 1, 26, 2.9, 0, 0.0, 0.0, ...

NULL, NULL, 0, 0.10, 300 );

DELETE FROM [SetUpHeights];DELETE FROM [CalcWindDirections];DELETE FROM [Swells];DELETE FROM [WaveReductions];DELETE FROM [Fetches];DELETE FROM [ForelandModels];

The closure scenarios are combined in the calculation scheme routines (FBC, APT and NTI)for each wind direction (see Figure 2.11); i.e. the loop over closure scenarios is nested withinthe loop over wind directions. Each scenario consists of a combination of closing situation,closing criterion, a reversed flag and a probability of occurence. The pre-processed designpoints for closure criteria are only used in case:

1 Multiple closure situations and scenarios exist (i.e. there is a closable storm surge in thecurrent region that can fail) [GCS1] and

2 A closure criterion exists (i.e. the criterion for closure is defined and pre-processed)[CCS3]

In case the first requirement is not met, the entire combination procedure for closure scenariosis skipped and the design point for the single closing situation available is used in the contin-uation of the computation. In case the second requirement is not met, there is no criterion forclosure available from the pre-processor (but may be included in the hydraulic data already)and for each closure scenario, the design points for the corresponding closing situation is sim-ply multiplied with the scenario probability2 and subsequently the design points for all closurescenarios are combined [CCS4a/CCS5/CCS7].

In case both requirements are met, each pre-processed design point for the current winddirection and calculation scheme is combined with the design point for the closing situationcorresponding to each closure scenario [CCS4b/CPE5]. Each combination result is then con-verted to a probability of exceedence and multiplied with the probability of occurence of thedesign parameter used in the pre-processor [CPE7]. The latter is based on the probabilitydensity derived from the U -values stored in the HRD database [CPE6]. The result is a designpoint for each closure scenario, given a value for the design parameter.

Next, all design points for a single closure scenario are combined and the result is multipliedwith the scenario probability [CPE8/CCS5]. The resulting design points include the contri-bution of the design parameter used in the pre-processor. Originally this parameter was setas deterministic value, but now the probabilities of these values are included. However, thiscontribution is not yet reflected in the α-values for each scenario. Therefore, the α-value forthe design parameter is set and the other α-values are scaled accordingly to keep the sum of

2Closure scenarios with zero probability are not supported and will cause a fatal error [CCS2]

Deltares 23 of 106


Figure 2.11: Conceptual sequence of the closure scenarios combination algorithm. Thecodes between brackets refer to the source code comments.

the squares unity [CPE9]:

αdesign = − udesignβscenario

(2.3)

α = α ·√

1− α2design (2.4)

Finally, all design points for the closure scenarios are combined in a single design point, which

24 of 106 Deltares


is returned to the calculation scheme routine [CCS7]. An overview of the combination routinefor closure scenarios is given in the diagram as visualized in Figure 2.11 (codes betweenbrackets refer to the source code comments).

The results are of the preprocessor are stored in the HRD database in the following fields:

� AlphaClosingCriterions, in which the α-values are stored for each variable, includingits duration,

� BetaUClosingCriterions, in which the reliability index β and the designpoint U arestored, for each combination of uncertainty choice, calculation scheme (FBC, NTI, APT)and wind direction,

� ClosingCriterions, in which the coupling with the prediction error load variable ID islaid,

� ClosingCriterionsPerDirection, in which the closure criterion ID is defined for thetab BetaUClosingCriterions,

� ClosingScenarios, in which the key information per closure scenario is stored with de-scription and scenario probability

� ClosingSituations, in which the potential situations are stored (open/closed).

2.4.2 The water system Easternscheldt

The water system Easternscheldt is a complex water system, due to the existence of theEasternscheldt storm surge barrier on one hand and due to the use of IMPLIC stations on theother hand. The storm surge barrier can fail in multiple ways; the IMPLIC stations (about 10in number) comprise stations for which the one-dimensional IMPLIC model has been used togenerate hydraulic data for a wide range of basic random variable realisations.

Three types of locations are relevant for the implementation of the water system Eastern-scheldt:

1 the stations for the basic random variables (the open sea for the sea water level, a fixedwind station for the wind),

2 the IMPLIC locations for which the one-dimensional flow model has computed hydraulicloads,

3 the toe locations along the shore of the Easternscheldt.

A direct computational link from the set locations ‘1’ towards the toe locations ‘3’ has provedproblematic in the past (cf. Projectbureau VNK (2009)). Hence, for Hydra-Ring a differenttechnique is designed. This design is based on the core concept of the derivation of thestatistics at the IMPLIC locations ‘2’.

The hydraulic database for these locations ’2’ is still capricious due to the storm surge barrierclosure behavior, which leads to poor convergence of FORM. A preprocessor is designed toavoid these problems, by preprocessing part of the statistics defined at the IMPLIC locations.

The preprocessor uses the method of numerical integration, to ’solve’ part of the hydraulicdatabase. The concept is briefly highlighted in Figure 2.12, and is further elaborated inDeltares (2016c). The standard Hydra-Ring NINT technique is adjusted to work with the’prestatiepeilen’ model, used to determine water levels for extreme conditions in the EasternScheldt (see Rijkswaterstaat (2008)).

The idea of the preprocessor is to simplify part of the hydraulic database by determining thedesign water levels for part of the variables. Mathematically the following integral is solved to

Deltares 25 of 106


Figure 2.12: Conceptual image that elucidates the concept of numerical integration ofprobability densities over the failure space, i.e. the space for which Z < 0,or equivalently H > h.

calculate the probability of a water level occuring:

P (H > h) =

∫hu

∫s

∫∆

∫Ts

∫h0

∫θ

∫U

f(hunc, U, θ, h0, Ts,∆, s)dUdθdh0dTsd∆dsdhu

(2.5)

In which:

H = Relevant range of water levelsh = Water level for which the probability is calculatedU = Wind speedθ = Wind directionh0 = OS11 water levelTs = Storm duration∆ = Tidal phase differences = Closure scenariohu = Water level uncertaintyf = Probability density function of the water level

The preprocessing module solves the following part of this integral for every location, winddirection and wind speed:

P (H > h|U ; θ) =

∫hu

∫s

∫∆

∫Ts

∫h0

f(h0, Ts,∆, s|U ; θ)dh0dTsd∆dsdhu (2.6)

Solving this integral leads to an exceedance probability for every water level in the requestedrange. The output of the preprocessor is thus an exceedance probability curve at each ofthe IMPLIC stations, conditional to the wind speed and the wind directions. The conceptualoutput of the preprocessor is shown in Figure 2.14.

2.4.2.1 Outline

The outline of the preprocessor is as follows:

26 of 106 Deltares


Figure 2.13: Conceptual image of the result of the preprocessor for three wind speedsand two wind directions. The water level h (at an IMPLIC location) is visu-alized on the vertical axis, whereas the return period, associated with theconditional probability, is visualized on the horizontal axis.

1 Determine an exceedance frequency curve for each combination of:

� Implic station� wind speed� wind direction.

2 To do so, determine the exceedance probability of each water level step, which is equal tothe product of the following factors:

� tidal phase difference� storm duration� OS11 water level� closure scenario� the probability of the uncertainty in the water level

leading to a higher water level than the reference water level.Each of these factors needs to be determined, so:

3 Determine the tidal phase difference4 Determine the storm duration5 Determine the OS11 water level6 Determine the probability of failure for the closure scenario7 Determine the probability of the water level uncertainty

Each of the numbered steps in the list will be elaborated further with pseudocode, formulasand figures to clarify its functioning.

2.4.2.2 Determine the exceedance probability curves

For each location, each wind direction and each wind speed, an exceedance probability curveis be calculated. The basis of the preprocessor is the triple loop that goes along all thesecombinations, presented with the following pseudo code.

for each IMPLIC station dofor each wind direction do

Deltares 27 of 106


for each wind speed docalculate the exceedance frequency curve

end forend for

end for

Following this procedure leads to a set of exceedance frequency curves for each wind speedand wind direction, per location.

2.4.2.3 Determine an exceedance frequency curves

Each exceedance frequency curve (or exceedance probability curve) can be determined bycalculating the exceedance probability per water level in the relevant range. To do so, foreach combination of phase difference, OS11 water level, storm duration and closure scenariothe exceedance probability of the water level, given the circumstances (wind speed, winddirection) is calculated. The exceedance probability of a water level is given by the followingmathematical equation:

P (H > h|U,Θ) =∑x∈X

Px [himp,x > h] (2.7)

In which:

X = Set with combinations of h0, Ts, ∆, s and hux = realization of set XPx = Probability of xhimp,x = Water level at IMPLIC station given x

Px [himp,x > h] can subsequently be expressed mathematically as:

Px [himp,x > h] = P∆,x ·PTs,x ·Ps,x ·Ph0,x ·Phu,x (2.8)

In which:

P∆,x = Probability of specific phase differencePTs,x = Probability of specific storm durationPs,x = Probability of specific closure situationsPh0,x = Probability of specific OS11 water levelPhu,x = Probability of specific water level uncertainty

The water level himp,x is extracted from the IMPLIC results, of which an example is shownbelow. The condition himp,x > h in equation 2.7 is processed within Ps by only consideringclosure scenarios that satisfy himp,x > h.

# Deze serie sommen is gedraaid zonder gebruik te maken van de WTZ-database# Kolom-omschrijving:1 Scenario2 Stormduur [uren]3 Faseverschil hoogwater en maximum opzet [minuten]4 Maximale waterstand OS11 [cm NAP]5 Windsnelheid [m/s]6 Windrichting [graden tov N]7 Referentiewaterstand Roompot Buiten [cm tov NAP]8 Roompot Buiten (RPBU) Maximum waterstand [cm tov NAP]

28 of 106 Deltares


9 Roompot Binnen (RPBI) Maximum waterstand [cm tov NAP]10 Burghsluis Maximum waterstand [cm tov NAP]11 Wemeldinge Maximum waterstand [cm tov NAP]12 Rattekaai Maximum waterstand [cm tov NAP]13 Marollegat (MRG) Maximum waterstand [cm tov NAP]14 Stavenisse (STAV) Maximum waterstand [cm tov NAP]15 Philipsdam West (PW) Maximum waterstand [cm tov NAP]16 Colijnsplaat Maximum waterstand [cm tov NAP]17 Zeelandbrug Noord Maximum waterstand [cm tov NAP]18 Roompot Buiten (RPBU) Maximum waterstand [cm tov NAP]19 Sluitgat Roompot Maximum verval [cm]20 Sluitgat Schaar Maximum verval [cm]21 Sluitgat Hammen Maximum verval [cm]SSF31 20 -320 150 10 30 9999 150 131 147 147 131 147 131 135 151 ...SSF31 20 -320 150 10 60 9999 149 130 146 146 130 146 130 134 150 ...SSF31 20 -320 150 10 90 9999 148 129 145 146 130 146 129 134 149 ...SSF31 20 -320 150 10 120 9999 148 129 145 145 130 146 129 134 149 ...

The technical implementation of the mathematical equations 2.7 and 2.8 is illustrated with thefollowing piece of pseudo code.

for each water level doset exceedance probability to 0

for each phase difference docalculate probability of phase difference

for each water levels OS11 docalculate probability of given water level at OS11

for each storm duration docalculate probability of storm duration

if calculating without uncertainties docalculate probability of closure scenarios

add product of the 4 probabilities to the exceedanceprobability

else if calculating with uncertainties dofor each water level uncertainty step do:

calculate probability of uncertainty stepcalculate probability of closure scenarios

add product of the 5 probabilities to the exceedanceprobability

end forend if

end forend for

end for

calculate design point from probabilities

end for

Note that the design point for each water level (that is, the most likely load combination leadingto the water level), is also stored and saved.

Deltares 29 of 106


2.4.2.4 Calculate probability of tidal phase difference

The phase difference between tide and storm duration follow a uniform distribution, since thereis no correlation between the two variables. Given the uniform distribution and the discretesteps, the probability of a phase difference can be calculated with:

P∆,x =1

N∆

(2.9)

In which:

N∆ = The total number of phase differences

In pseudo code this simply looks as follows:

probability of phase difference = 1.0 / number of phase differences

2.4.2.5 Calculate probability of storm duration

The storm duration is calculated from a shifted lognormal distribution. The system specificparameters are Since the storm duration is integrated by classes, the probability of a certainclass is calculated from the difference between the probabilities of the class beginning andend, as shown in equation 2.10.

Pts =

∫ ts+ 12

∆ts

ts− 12

∆ts

f(s)ds = F

(ts +

1

2∆ts

)− F

(ts −

1

2∆ts

)(2.10)

With:

Pts = PTs,x

Note that in equation 2.10 the class steps of the storm duration are depicted as fixed steps(∆ts), but this is not necessarily the case. For the first and last step respectively the lowerand upper limit are left out. As is clarified in the following pseudo code.

read the storm duration number

if (storm duration number = 1) docalculate the upper limit of the storm duration classcalculate the cumulative probability of the upper limit

else if (storm duration number = number of storm durations) docalculate the lower limit of the storm duration classcalculate the exceedance probability of the upper limit

else docalculate the upper limit of the storm duration classcalculate the cumulative probability of the upper limit

calculate the lower limit of the storm duration classcalculate the cumulative probability of the lower limit

subtract the cumulative probability of the lower limit of the cumulativeprobability of the upper limit

end if

30 of 106 Deltares


2.4.2.6 Calculate the probability of the water level OS11

When calculating the probability of a water level at OS11, the correlation of the water levelto the wind speed (at Vlissingen) is included. To do so, the probability without correlation iscalculated, after which the factor of the wind speed probability is added. Both actions will bedescribed subsequently.

Note that calculating the correlated probabilities is done only once before going throughthe main loop, since the probabilities are independent of phase difference, storm durationetcetera, and take relatively long to calculate.

Uncorrelated to the wind speed

To determine the probability of the sea water level, the location OS11 outside of the stormsurge barrier is used. At this location the exceedance probability of a specific water level iscalculated with the conditional Weibull distribution:

P (H > h|R = r) = λ · exp

{−(h

σr

)α+

(ω

σr

)α}(2.11)

In which:

R = Wind direction with realisation rσ = The scale parameterα = Shape parameterω = Threshold valueλ = Probability of the threshold

Note that this distribution gives the exceedance probability. To calculate the probability ofa certain OS11 water level range, two subsequent exceedance probabilities are subtracted.Graphically the Conditional Weibull distribution looks as depicted in Figure 2.14 for one winddirection.

Figure 2.14: Example of the conditional Weibull distribution the model the water level atOS11.

set water level probability to 0

for each water level in the relevant range docalculate probability of a water level range from a conditional Weibulldistribution as follows:

if (water level number = 1) do

Deltares 31 of 106


calculate the upper limit of the water level classcalculate the cumulative probability of the upper limit

else if (water level number = number of water levels) docalculate the lower limit of the water level classcalculate the exceedance probability of the upper limit

else docalculate the upper limit of the water level classcalculate the cumulative probability of the upper limit

calculate the lower limit of the water level classcalculate the cumulative probability of the lower limit

end if

subtract the cumulative probability of the lower limit of the cumulativeprobability of the upper limit

end for

Correlated to the wind speed

The exceedance probability of the OS11 water level can be calculated with the Weibull distri-bution in the described way, but this neglects the correlation with the wind speed.

To include the effect of correlation, the probability of the water level is multiplied by the prob-ability of the wind speed given the specific water level. This gives the following mathematicalequation for the exceedance probability:

P (H0 > h0|U = u) =

∑P (h0,i|ρ = 0) ·P (U |h0,i)[h0,i > h0]∑

P (h0,i|ρ = 0) ·P (U |h0,i)(2.12)

In which:

ρ = The (Pearson) correlation coefficient, in this context only used to indicate thelack of correlation

So the sum of all correlated probabilities leading to an exceedance of the OS11 water level isdivided by the sum of all correlated probabilities, to get the correlated exceedance probabili-ties.

Each step h0,i for a certain wind speed spans the IMPLIC discretization step for the waterlevel and the wind speed. It thus spans a block in the two-dimensional U , H0 grid, and istherefor called a block probability:

Pbl = P (h0,i|ρ = 0) ·P (U |h0,i) (2.13)

The problem with the block probabilities is that the probability of the wind speed is highlydependent on the OS11 water level, and the implic water level step size (10 cm) is too large todescribe the correlation correctly. To solve this problem, the OS11 water levels within a blockis further divided into 10000 very small lamellae, for which the probabilities is summed:

Pbl =10000∑j=1

P (h0,i,j|ρ = 0) ·P (U |h0,i,j) (2.14)

The process of calculating the block probabilities is described with the following pseudo code:

32 of 106 Deltares


set water level probability to 0

for each water level in the relevant range doset block probability to 0

for each part of the water level range docalculate probability of the specific part from a conditional Weibulldistribution as described by the last pseudo code block

read correlation parameter

calculate wind speed probability given the specific water leveland correlation parameter with the PCR correlation model

calculate the product of the water level probability and thecorrelated wind speed probability

block probability = block probability + product

end for

end for

Correlation model

PCR is the model used to calculate the correlated probability of a wind speed P (U |h0,i,j).PCR is described into detail in Deltares (2016c), and will not be described here.

2.4.2.7 Calculate closure scenario probability

The closure scenario probability gives the probability that a water level is exceeded, giventhe storm surge barrier functioning. A water level of 2 meters above NAP for example, hada closure scenario probability of 1.0, since it can be exceeded in all different scenarios. Awater level of 10 m above NAP (hypothetically) can only be reached if the complete barrierfails, and thus had a much lower probability. So to calculate the closure probability, the sumof the failure probabilities leading to a higher water level than the reference water level at thespecific Implic-station is used. In total 2× 9 = 18 failure scenarios are considered, of whichthe probabilities are shown below.

Number of failing locks Manned Unmanned0 locks 0.9864754288 0.93950690531 lock 0.0118000000 0.05410000002 locks 0.0003810000 0.00183000003-5 locks 0.0001880000 0.00200000006-10 locks 0.0005880000 0.000972000011-16 locks 0.0003770000 0.0006070000half of the barrier 0.0001700000 0.0002310000three quarters of the barrier 0.0000000712 0.0000000947complete barrier 0.0000205000 0.0007530000

Table 2.1: Probabilities for different closure scenarios

The probabilities given in the table are conditional to the four closure modes of the barrier:

Deltares 33 of 106


� Emergency closure� Manned closure 3.00 m + NAP� None closure� Strategical closure

The probability of each closure mode is conditional to the water level. Figure 2.15, adoptedfrom Rijkswaterstaat (2008) nicely depicts the probability of each mode over the relevant rangeof water levels at Roompot Buiten.

Figure 2.15: Probabilities of different types of closure as function of the maximum waterlevel. The figure is taken from Rijkswaterstaat (2008).

To calculate the probability of the closure scenarios given a specific water level, the probabilityof each closure type and scenario (figure 2.15 and table 2.1) are calculated and summed ifthe water level of the specific combinations exceeds the water level at which the probabilitiesare calculated. Equation 2.15 described this mathematically.

P (H > h|∆, x;Ts, x;h0, x) =∑s∈S

Ps [himp,x > h] (2.15)

In which:

S = Set of closure scenario’s

The probability Ps is the product of the closure type probability and the closure failure proba-bility, which is conditional to the closure type. So:

Ps = Ptype ·Pfailure|type (2.16)

The following pseudo code clarifies the technical implementation of the closure scenario prob-ability.

if none closure doset pscenario to 1

34 of 106 Deltares


else doset pscenario to 0

for each closure type do

for each closure scenario doread probability closure typeread probability closure scenariocalculate probability of specific scenario

read implic water level for specific scenario

if implic water level > water level dopscenario = pscenario + probability of specific scenario

end ifend for

end forend if

2.4.2.8 Calculate water level uncertainty

The uncertainty probability gives the probability of a certain shift in water level, due to statisti-cal or model uncertainty. The water level uncertainty is derived from a probability distributionthat can be conditional to the wind direction speed. The numerical discretization of the waterlevel uncertainty is based on the grid in standard normal space, instead of a water level grid.

P (Bunc = βunc|U ; Θ) = F−1

(βunc +

1

2∆βunc|U ; Θ

)−F−1

(βunc −

1

2∆βunc|U ; Θ

)(2.17)

In which:

Bunc = the standard normal variable rangeβunc = the standard score, also known as the z-scoreF−1 = the inverse cumulative distribution of the water level uncertainty

The grid B spans a standard score of -10 to 10. For each step the probability is calculated,given the specific distribution. In pseude code the implementation is as follows:

for each step on the standard normal grid do

upper limit = step + 1/2 stepsizelower limit = step - 1/2 stepsize

if (uncertainty step = 1) doprobability = 1 - exceedance probability of upper limit

elif (uncertainty step = number of uncertainty steps) doprobability = exceedance probability of lower limit

else doprobability = (exceedance probability of upper limit)

- (exceedance probability of lower limit)end if

Deltares 35 of 106


determine the parameters of the probability distribution given the winddirection and speed

determine the water level shift from the inverse uncertainty distribution

round the water level shift to the nearest hOS11 step

end for

2.4.2.9 Output

The output of the preprocessor is a set of exceedance probability curves for the water levelat all the IMPLIC locations, conditional to the wind speed and the wind direction. This set ofcurves is stored as tables in the Hydraulic Region Database for the Easternscheldt region.In the core of Hydra-Ring, these tables are combined with the regular wind statistics (i.e. forwind speed and wind direction) in order to compute failure probabilities at toe locations alongthe shore of the Easternscheldt.

2.4.3 The water system Dunes

For each water system, the hydraulic loads are stored in the Hydraulic Region Database(HRD). The hydraulic loads at specific locations along the axis and/or shore of a certain watersystem are precomputed by means of deterministic models, like WAQUA. Practically, all thewater systems follow this approach, enabling the definition of a general setup for the HRD’sof the complete set of water systems.

For computational reasons, a deviation from this approach is followed for the Easternscheldtregion. For this region, the translation of the basic random load variables to the load locationsalong the shore of the Easternscheldt is intervened by the computation of the statistics at theintermediate IMPLIC locations. This system is the first exception on the general approach forthe HRD generation procedure.

The second exception of the general HRD generation procedure comprises the water systemDunes. The statistics for this water system are described in § 3.7 of Chbab and Eilander(2016), and references therein. The setup of this water system Dunes, however, does notfit into the picture of the general setup of the HRD generation procedure, since this setup isdirectly based on the multiple auxiliary points (mentioned in Chbab and Eilander (2016) assteunpunten (in Dutch)).

In order to satisfy the generality of the Hydraulic Region Databases, the preprocessor for thewater system Dunes is built. The concept of this preprocessor is extremely simple: convertthe statistical and hydraulic data from the auxiliary points (Vlissingen, Hoek van Holland,IJmuiden, Den Helder, Eierlandse Gat, ‘Extra Steunpunt’ and Borkum) to each individualJarkus-location. For this, the lookup table 3.26 in Chbab and Eilander (2016) is used.

The computational element of the preprocessor is a direct implementation of expression (3.8)in Chbab and Eilander (2016) for the wave height Hs and expression (3.9) in Chbab andEilander (2016) for the wave period Tp. The sequence is as follows:

Determine the part of the interpolation curves and ...... interpolation for all the auxiliary points

Calculate waterlevels: Support 1 (using subroutine calculateDistributionInverse)

36 of 106 Deltares


Calculate waterlevels: Support 2 (using calculateDistributionInverse)Interpolate waterlevels between auxiliary pointsWave height: Support 1 (using expressions in Chbab and Eilander (2016))Wave height: Support 2 (using expressions in Chbab and Eilander (2016))Interpolate wave heights between auxiliary pointsWave period: Support 1 (using expressions in Chbab and Eilander (2016))Wave period: Support 2 (using expressions in Chbab and Eilander (2016))Interpolate wave periods between auxiliary pointsWave direction: equal to the Dune normalCorrection of the local wave height due to sandbanks

The result of the preprocessor for the water system Dunes is a dedicated HRD containing thewater levels and wave parameters at each Jarkus location. Hence, a probablistic computationfor just water levels is rather trivial.

2.4.4 Eliminated effects of wind directions

This section described a specific preprocessor to switch off specific wind directions. Thispreprocessor is not part of the default settings of Hydra-Ring, but is meant as a potential toolfor experts.

The calculation of the marginal wave statistics is done by the HydraRing probabilistic kernel.The computation contains several steps, where an important part is the loop over all winddi-rections. Within each winddirection a probabilistic computation is performed using techniquesas FORM (First Order Reliability Method), DS (Directional Sampling) and FDIR: a combinationof FORM and DS. FORM is a very fast method, but it does not always converge. DS takes alot of computation time, and gives an answer if you use enough samples. FDIR is combinationwhere at first FORM is tried, and if that fails a DS computation is performed.

In the case of marginal wave statistics it is found that winddirections where FORM does notconverge, have a very small contribution to the total statistics. It is suggested to use a prepro-cessing stage to deselect the winddirections which have a very small contribution to the totalstatistics, and avoid many DS computations.

A normal Hydra-Ring computation is steered using an ini-file with references to other datasources (be aware: the numbering, between square brackets, is not part of the file; it is onlyused to benefit the description in the text below):

[ 1] section = 43[ 2] mechanism = 101[ 3] alternative = 1[ 4] layer = 1[ 5] logfile = hydraring.log[ 6] outputverbosity = basic[ 7] outputtofile = file[ 8] projectdbfilename = myproject.sql[ 9] configdbfilename = mydirectory/artefacts/config.sqlite[10] hydraulicdbfilename = mydirectory/Hydraulic Databases WTI2017/HLCD.sqlite[11] outputfilename = myproject/designTable.txt[12] availablecores = 4

Through this initialization file, one single computation will be launched for one single mech-anism (with ID 101) at one single location (with ID 43, linked to the contents of the file

Deltares 37 of 106


myproject.sql). The keywords alternative and layer are only relevant for geotechni-cal failure mechanisms and revetments, respectively. Lines 5, 6 and 7 refer to specific outputfiles, whereas line 9 refers to the template of the project database.

Together with lines 1 and 2, the lines 8 and 10 form the key of the initialization file. In line8, the project database is provided to the kernel, whereas in line 10 the hydraulic boundaryconditions are specified. Line 11 is only needed in case of the method ’iterate to given beta’or in case of the a table computation, and is the filename of an output file filled by this method.

The outputverbosity keyword can have the values none, basic, detailed and debugging,and determines the amount of logging. With availablecores the maximum number of corescan be set. By default, all cores will be used in parallel sections. Currently, this only affects alimited number of failure mechanisms.

The project database (inserted as ascii-type sql-file) for marginal wave statistics calcalutionlooks like :

DELETE FROM [HydraulicModels];INSERT INTO [HydraulicModels] VALUES (1, 1, 'WTI 2017');

DELETE FROM [Sections];INSERT INTO [Sections] VALUES ( 35, 1, 1, 'Cornwerd', 'Cornwerd', ...

153122, 565937, 153122, 565937, 700003, 700003, 100, 210, 1);

DELETE FROM [SectionFaultTreeModels];INSERT INTO [SectionFaultTreeModels] VALUES (35, 11, ...

1, 1, 13); -- Significant wave period;

DELETE FROM [Numerics];INSERT INTO [Numerics] VALUES ( 35, 11, 1, 1, 13, 5, 4, 50, 0.15, ...

0.01, 0.01, 0.01, 2, 1, 1000, 2000, 0.1, -6, 6, 25 );

DELETE FROM [DesignTables];INSERT INTO [DesignTables] VALUES ( 35, 11, 1, 1, 3, 29, NULL, 2.0, ...

6.4, 0.1, 3.0, 5.6, 3.29053 );

DELETE FROM [VariableDatas] ;INSERT INTO [VariableDatas] VALUES ( 35, 11, 1, 1, 29, 4.95, 0, 10.0, ...

0.02, NULL, NULL, 0, 0.10, 300 ); -- Reference wave period;

DELETE FROM [AreaPoints];DELETE FROM [PresentationSections];DELETE FROM [Profiles];DELETE FROM [CalculationProfiles];DELETE FROM [Forelands];DELETE FROM [ProbabilityAlternatives];DELETE FROM [SetUpHeights];DELETE FROM [Swells];DELETE FROM [WaveReductions];DELETE FROM [Fetches];DELETE FROM [ForelandModels];

DELETE FROM [Areas];INSERT INTO [Areas] VALUES (1, '1', 'Nederland');

DELETE FROM [CalcWindDirections];INSERT INTO [CalcWindDirections] ([SectionId], [MechanismId], [WindDirectionId], ...

[isUsed]) VALUES (35, 11, 1, 0);INSERT INTO [CalcWindDirections] ([SectionId], [MechanismId], [WindDirectionId], ...

[isUsed]) VALUES (35, 11, 2, 0);

38 of 106 Deltares


DELETE FROM [Projects];INSERT INTO [Projects] VALUES (1, 'Testbank', 'Hydra-Ring testbank');

Through the key CalcWindDirections, certain wind directions can be switched off (furtherexplained in section 4.3.17). The purpose of the wind directions preprocessing tool is toautomatically generate the lines starting with this key CalcWindDirections, based on thewave conditions found in the database with hydraulic boundary conditions. Thus, unimportantwind directions can be switched off.

The tool is based on an estimate of the mean wave height. In the section we give an exampleof the calculation of the mean wave height. Suppose have we the following table for winddirection 0◦ for Hs.

R = 0.000

Water level IJssel lake m + NAP|| Wind speed m/s\/ 0.000 14.000 19.000 22.000 25.000 28.000 31.000 34.000 38.000 42.000

--------------------------------------------------------------------------------0.400 0.000 0.729 1.020 1.211 1.402 1.606 1.829 2.049 2.350 2.627-0.100 0.000 0.754 1.051 1.251 1.451 1.656 1.882 2.105 2.422 2.7150.400 0.000 0.797 1.100 1.307 1.525 1.740 1.968 2.201 2.528 2.8471.000 0.000 0.842 1.162 1.372 1.594 1.825 2.063 2.312 2.641 2.9841.800 0.000 0.898 1.246 1.479 1.704 1.943 2.194 2.438 2.785 3.139

-------------------------------------------------------------------------------

Two approaches are possible:

� medianIndex, for instance: 10 windspeeds given, use mean of 25 en 28 and 5 WaterlevelsIJssel lake given, use value for 3th = 0.4 deliver waveheight = mean(1.525, 1.740) =1.6325,

� meanMinMax, for windspeed = mean(42,0) = 21 and Waterlevel IJssel lake = mean(-.4,1.8) = 1.1 deliver waveheight = interp(1.162, 1.246, 1.372, 1.479)≈ 1.3.

This can be extended in a later version with a fraction x, e.g. x = 0.40. Currently, only theoption meanMinMax is implemented.

The reading of the ini-file can be reused from the routine readInifile which fills a struct oftype typeContentInifile. Optionally, the ini-file is extended with e.g. a threshold value.The reading of the hydraulic database can be reused from the routines getUserData andgetData. They fill a struct of type hydraRingData. This is the main part of the tool, and hasto be newly written. The related pseudo code is as follows:

subroutine getIgnoredWinddirections(in: sectionId, out: ignoreWinddirs)

do i for all winddirectionsget hydraulic tables for open conditionsget mean waveheight, using meanMinMaxstore waveHeight(i)

end do

Deltares 39 of 106


maxWaveHeight = maxval(waveHeight)

threshold = thresholdParameter * maxWaveHeight! thresholdParameter = 0.25 or user-defined

do i for all winddirectionsignoreWinddirs(i) = ( waveHeight(i) < threshold )

end do

end subroutine getIgnoredWinddirections

The main program can call this function for multiple sections. This is the last part of the tool,and has to be newly written. The related pseudo code is as follows:

subroutine writeIgnoredWinddirections(in: filenameSql, ignoreWinddirStruct)

open filenameSql in append modewriteline(`DELETE FROM [CalcWindDirections]')do i = 1, size(ignoreWinddirStruct)

if ignoreWinddirStruct(i)->ignoreFlag thenwriteline(`INSERT INTO [CalcWindDirections] VALUES ` , ...

ignoreWinddirStruct(i)->sectionId , ...ignoreWinddirStruct(i)->mechanismId , ...ignoreWinddirStruct(i)->windDirectionId , 0)

endifend doclose filenameSql

end subroutine writeIgnoredWinddirections

This function can be used for multiple sections and mechanisms. Note that the rest of the toolonly handles mechanismId = 11.

2.5 Non-functional aspects

Hydra-Ring will meet the functional and technical requirements as described in Deltares(2016a). Hydra-Ring will also meet the aspect views depicted in this section.

2.5.1 Data-integrity

Data-integrity will be guaranteed by a clear data definition and a complete data model. Eachdata entity has a unique role and is as such part of the underlying data model as a fundamentof the database design. This database design is further elaborated in chapter 4. Every tablein the database will have a primary key to guarantee data integrity on a database level. Thecolumn in the table to be chosen as primary key will be unique and not null.

2.5.2 Data-inconsistency

If an input parameter is changed, the corresponding output results do not correspond any-more. Hydra-Ring must have functions that check changes in the input data interface. Theconsistency between the input data and the associated output data must be guaranteed. Inorder to meet this concept, section 3.6.3 elaborates on the joint existence of input log filesand output log files.

40 of 106 Deltares


2.5.3 Robustness

The User Interface will check whether the input data are within certain ranges preventing un-realistic input data. If possible, the User Interface will also check for unrealistic combinationsof input parameters. The programming code itself will also have a robustness design by de-tection of convergence problems for instance and a clear error handling (QR5, QR12, QR16).Although this approach might suggest responsibility of the User Interface, the key responsi-bility lays at the failure probability modules, that are connected to the User Interface and thecomputational core in full modularity. This modularity is elaborated in section 3.2.

2.5.4 Plausibility checks

If possible, it will be checked if results of computational methods are within plausible ranges(QR5). In many cases, such checks will directly be performed by the computational kernelsfor the failure mechanisms themselves, as a result of the modular architecture of the software.This modularity is elaborated in section 3.2.

2.5.5 Consistency

Consistency of Hydra-Ring, e.g. Hydra-Ring functions according to specifications, will beguaranteed by quality assurance and test procedures. A well-defined test philosophy, testcases and testbench (QR6, QR18) are part of the test plan. Scientific tests guarantee testingof the implemented, scientific algorithms. The test philosophy and associated proceduresare described in Deltares (2016d). For full consistency during the software development, theversion management tool Subversion is used. The tool TeamCity is used for the automizedbuilding and testing procedures (QR21).

2.5.6 Data recovery

Additional measures for data recovery of failed, damaged, corrupted or inaccessible measuresare not implemented. Preventing inconsistent or damaged data relies on the implementeddatabase management system.

2.5.7 Parallellisation

Nowadays, multi-core processors are common. A multi-core processor is a single computingcomponent with two or more independent actual processing units (called cores), which arethe units that read and execute program instructions. The instructions are ordinary CPU in-structions, but the multiple cores can run multiple instructions at the same time, increasingoverall speed for programs amenable to parallel computing. A multi-core processor imple-ments multiprocessing in a single physical package.

The concept of parallellisation is visualized in Figure 2.16. For Hydra-Ring, the parallellisa-tion approach with OpenMP is followed. OpenMP (Open Multi-Processing) is an applicationprogramming interface (API) that supports multi-platform shared memory multiprocessing pro-gramming. OpenMP uses a portable, scalable model that gives programmers a simple andflexible interface for developing parallel applications for platforms ranging from the standarddesktop computer to the supercomputer.

For the design of Hydra-Ring, advantage is taken from this multi-core processors that arenowadays commonly available. The parts of the Hydra-Ring computational sequence thatare most suitable for parallellisation are the computational technique FORM and, particularly,the computational technique Directional Sampling. The implementation of OpenMP within theFORM procedure is shown in Figure 2.17.

Deltares 41 of 106


Figure 2.16: The concept of parallellisation over multiple cores.

Figure 2.17: Implementation of the parallellisation through OpenMP within the FORM pro-cedure.

Sampling techniques, such as obviously Directional Sampling, are most suitable for parallelli-sation. Each different sample is treated by another core. Finally, the results are wrapped upto one single result that should exactly be equal to the result obtained over one single core,as long as a fixed seed procedure is followed. The implementation of OpenMP within theDirectional Sampling procedure is shown in Figure 2.18.

Both Figure 2.17 and Figure 2.18 show that the OpenMP implementation is basically a for-loopover the available threads.

42 of 106 Deltares


Figure 2.18: Implementation of the parallellisation through OpenMP within the DirectionalSampling procedure.

Deltares 43 of 106


44 of 106 Deltares

3 Interface design description

This chapter describes how Hydra-Ring communicates with the various modules. To that end,the module dependencies are first mapped in section 3.2. Thereafter, the plugin for failuremechanisms is described in section 3.3, enabling the user to connect new failure mechanismshimself, which is described in section 3.4. Failure mechanisms might require a prepatorycomputation (for instance macrostability, see Deltares (2016c)); the way Hydra-Ring dealswith prepatory computations is described in section 3.5. The interface with the User Interfaceis described in section 3.6. Aspects of the workflow in case of malfunctioning are addressedin section 3.7.

3.1 Purpose

As described in the Functional Design (see Deltares (2016a)), the software is to be con-structed in such a way that core Hydra-Ring functionality is set apart: the primary responsi-bility of Hydra-Ring is to compute failure probabilities. In order to distinguish responsibilities,other functionality than for computing failure probabilities is set apart as well.

The modular design, subdividing the system in multiple modules, enables the independentcreation of modules and the independent use of modules in different systems. A modularsystem can be characterized by functional partitioning into discrete scalable, reusable mod-ules, rigorous use of well-defined modular interfaces, and making use of industry standardsfor interfaces.

Besides the advantages of independent creation and independent use, benefits are gainedregarding costs, augmentation (adding new solutions by merely plugging in a new module)and exclusion. These benefits span the purpose of the modular design of the software system.

In addition to the gain of the mentioned benefits, the purpose of the modular setup is to enablethe advanced user (not being a Hydra-Ring programmer) to extend the software towards newor alternative failure mechanisms without the need to program new modules.

3.2 Module dependencies

As described in the Functional Design Deltares (2016a), the WTI-software contains a user-interface layer, a business layer and a data layer. The business layer should be able to con-sume information from distinct modules, particularly failure mechanisms. The failure mecha-nisms are managed outside the Hydra-Ring environment.

The dependencies of Hydra-Ring on other components is visualized in Figure 3.1. Hydra-Ringhas two key dependencies:

1 on failure mechanisms for dykes, dunes and structures,2 on probabilitic routines (such as FORM, Directional Sampling and so on).

The failure mechanisms are presented by unique dynamic link libraries (dll’s) that containthe routines that represent the functionality described by a functional design and a technicaldesign of each individual failure mechanism. The dll of an individual failure mechanism caneither be written in C# or in Fortran. The Hydra-Ring kernel is written in Fortran.

In order to enable communication between the failure mechanism dll’s and Hydra-Ring, so-called wrappers are introduced. A wrapper is a piece of software that provides a compatibilitylayer to another piece of software and can be perceived of as the receiving entity of informationfrom distinct modules. The correct functioning of failure mechanisms dll’s is a responsibility

Deltares 45 of 106


Figure 3.1: Dependencies of Hydra-Ring on multiple modules.

of the functional application managers of the individual routines and hence not of the WTI-software.

The functional routines for the hydraulic boundary modules (i.e. marginal statistics for waterlevels and wave parameters, and the Q-variant) are located within the Hydra-Ring environ-ment, be it as a distinct modules. These modules are within the responsibility of the Hydra-Ring functional application manager.

Besides the failure mechanisms and the hydraulic boundary modules, one external moduleis present that is not captured by any preceding category, namely the dam and foreshoremodule (see Kramer (2016)). This module is basically a transformation routine that reduceswave parameters under influence of damping effects induced by dams and/or foreshores.Previously, the wave growth formula Bretschneider was supported as well in a technical wayalike; however, this module is deprecated since individual outcomes are stored in the HRDdatabase.

The probabilistic routines are written in Fortran. Each probabilistic routine performs, concep-tually, nothing more than a iterative calling of a failure mechanism module. The probabilisticlibrary is usable for other parties or projects. Within the probabilistic routines, parallel comput-ing is possible by means of OpenMP.

Figure 3.1 shows a box named in which ‘DSL-core’ is mentioned. DSL stands for Delta ShellLight, which is the name of a framework of geotechnical user-interface software. It is im-portant to mention that Hydra-Ring does not directly depend on DSL. However, some failuremechanisms (for instance macrostability) run on the DSL framework via the user-interface ofalready existing software. The dependency of a failure mechanism on DSL is a matter of thefunctional application manager of the failure mechanism module concerned.

46 of 106 Deltares

Interface design description

3.3 Plugin for failure mechanisms

Failure mechanisms are provided as external binaries for Hydra-Ring and Ringtoets. BothHydra-Ring and Ringtoets will have to connect to the failure mechanisms. The following ob-jectives have to be met when implementing the connections:

1 Ringtoets and Hydra-Ring will have independent implementations of the connections.2 Ringtoets and Hydra-Ring should use the same release/version of each failure mecha-

nism.3 If there are shared libraries then Ringtoets, Hydra-Ring and each failure mechanism

should use the same release/version of the libraries.4 It should be possible to connect a new Failure mechanism without recompiling Hydra-Ring.

Connecting the failure mechanism is done by changing the configuration of Hydra-Ringthrough the configuration database.

In the current implementation of Hydra-Ring all of these requirements are met, except for thefailure mechanism macrostability. Macrostability has a specific implementation that does notfit in the general approach (in section 3.5, this issue is further commented on). In Figure 3.2,the architecture of the implementation is shown.

Figure 3.2: Visualisation of the architecture of the WTI2017 software. Four parts are to bediscerned: a Hydra-Ring branch, a Ringtoets branch, a failure mechanismsbranch and a Delta Shell Light branch.

In this figure, the following components are depicted:

1 DSL-Geo and DSL-Core are separate libraries which are used by some failure mecha-nisms. These libraries are part of the Delta Shell Light Framework.

2 The failure mechanisms are (independent) libraries which are shared by Ringtoets andHydra-Ring.

3 For Ringtoets, C# wrappers will be used to connect to the failure mechanisms.

Deltares 47 of 106


4 For Hydra-Ring, C++ or Fortran wrappers will be used to connect to the failure mecha-nisms. A Fortran wrapper will be used for a failure mechanism that is written in Fortran(e.g. Overtopping). A C++ wrapper will be used for a failure mechanism that is written inC# (e.g. piping) or C++ (currently no failure mechanisms are in C++).

5 To be able to integrate a plugin in a generic way, the Fortran and C++ wrappers have awell-defined interface. Three functions can be defined for a plugin failure mechanism:

� GetZValue (mandatory),� Initialize (optional),� Finalize (optional).

The interfaces for C++ and Fortran are specified below.

The C++ interface for plugin failure mechanism is as follows:

int GetZValue(double *z, double *x, int *xLength, typeInputStruct *inputStruct,typeResultStruct *resultStruct);

The result is 0 when the ZValue invocation is successful, otherwise it will be not 0 (e.g. -1).The input parameters are:

z = resulting z-valuex = x-vector with stochastic valuesxLength = length of x-vectorinputStruct = structure with additional input values (see below)resultStruct = structure with additional output values (see below)

The struct definitions are:

struct typeInputStruct = {double waterLevel; // water leveldouble waveHeight; // wave heightdouble wavePeriod; // wave perioddouble waveDirection; // wave directionint calculationParameter1; // optional f.m. specific number,int calculationParameter2; // idem,

// could be used e.g. for Macro Stability// 1 = prepatory call// 2 = main calculation// or the Model ID in Structures (Linear/Quadratic)

int dataSize; // size of following datablockchar dataBlock[30000]; // fixed sized datablock

// the content of this block is f. m. specific// and can and should be only interpreted by the// failure mechanism. Hydra Ring will only read the data

// from the project database and pass it via// this datablock.}

Struct typeResultStruct {double result1; // f.m. specific extra result parameterdouble result2; // f.m. specific extra result parameter

48 of 106 Deltares


}

int Initialize(char* data, int *lengthData)

int Finalize()

For the last two steps, the result is 0 when the invocation is successful, otherwise it will be not0 (e.g. -1).

The C++ interface for plugin failure mechanism is as follows:

struct typeInputStruct {double waterLevel; // water leveldouble waveHeight; // wave heightdouble wavePeriod; // wave perioddouble waveDirection; // wave directionint calculationParameter1; // calculation parameter 1; is not required,int calculationParameter2; // calculation parameter 2; is not required,int dataSize; // size of following datablockchar dataBlock[30000];

};

struct typeResultStruct {double result1;double result2;

};

/// <summary>/// Gets the z value/// </summary>/// <param name="z">The z.</param>/// <param name="x">The x.</param>/// <param name="xLength">Length of the x.</param>/// <param name="inputStruct">The input structure.</param>/// <param name="resultStruct">The result structure.</param>/// <returns> Error code (0 = no error)</returns>__declspec(dllexport) int _GetZValue(double *z, double *x, int *xLength,

typeInputStruct *inputStruct,typeResultStruct *resultStruct)

{}

/// <summary>/// Initializes the submechanism./// </summary>/// <param name="data">The data.</param>/// <param name="lengthData">The length data.</param>/// <returns>Error code (0 = no error)</returns>__declspec(dllexport) int Initialize(char* data, int* lengthData){}

/// <summary>/// Finalizes the submechanism./// </summary>/// <returns> Error code (0 = no error)</returns>__declspec(dllexport) int Finalize(){}

Deltares 49 of 106


3.4 Implementation of new failure mechanisms

One of the purposes of the software architecture is to enable an advanced user to implementa failure mechanism himself. The implemention of a plugin failure mechanism in Hydra Ringtakes 2 steps:

1 Create a wrapper according to the above definitions (one of the below options)

1a Fortran wrapper,1b C++ wrapper.

2 Configure the configuration database, so Hydra Ring can use the failure mechanism

These 2 steps will be described below with the failure mechanism structuresClosure2017(Fortran) and DuneErosion (C++) as examples.

3.4.1 Step 1a: Create a Fortran wrapper

In solution folder pluginFailureMechanisms create folder structuresClosure2017. In this foldercreate new Fortran project structuresClosure2017: see Figure 3.3.

Figure 3.3: Create a new folder for the failure mechanism plugin.

In the property pages change the settings according Figure 3.4 and Figure 3.5 and Figure 3.6.

Add a new Fortran source file structuresClosure2017.f90. This file will contain the functionsGetZValue, Initialize and Finalize. Set the correct subversion properties with Tortois-eSVN. From the windows explore select all Fortran files and right button click TortoiseSVN –Properties – New – Keywords and check the boxes according to Figure 3.7.

50 of 106 Deltares


Figure 3.4: Create a new folder for the plugin and adapt the ‘General’ tab.

Figure 3.5: Create a new folder for the plugin and adapt the ‘Fortran-Libraries’ tab.

Deltares 51 of 106


Figure 3.6: Create a new folder for the plugin and adapt the ‘Linker - General’ tab.

Figure 3.7: Check the boxes in the solution to assure the correct subversion properties.

52 of 106 Deltares


3.4.2 Step 1b: Create a C++ wrapper

In solution folder pluginFailureMechanisms create folder duneErosion. In this folder, createnew C++ project duneErosion, according to Figure 3.8.

Figure 3.8: Create a new folder for the project.

In the property pages change the following settings: the application settings according toFigure 3.9, the framework and references settings according to Figure 3.10, the general con-figuration properties according to Figure 3.11 and the general linker configuration accordingto Figure 3.12.

Deltares 53 of 106


Figure 3.9: Set the application settings by clicking the appropriate boxes.

Figure 3.10: Set the framework and references settings within the common properties.

54 of 106 Deltares


Figure 3.11: Set the correct framework and references properties.

Figure 3.12: Set the correct general configuration properties.

Deltares 55 of 106


3.4.3 Step 2: Configure the configuration database

The configuration of the database will be illustrated with the mechanism structures overtop-ping, because this mechanism is representative of how sub mechanisms can be combined ina fault tree. In Figure 3.13, it is shown which submechanisms contribute to this mechanism(Z11, Z12 and Z13) and how they are combined along the faulttree.

Figure 3.13: Failure tree of the mechanism ‘structure failure due to overtopping/overflow’.

The configuration is accomplished by filling the tables in the configuration database. In Hydra-Ring the configuration database is filled with the script FillCD.sql. The following tables areto be filled:

1 MainMechanisms: This setting is important for the Combine functionality. In this case:

MainMechanismId = 107Name = 'Structure overtopping 2017'

2 Mechanisms: Here you can set the mechanism which contains all the submechanisms. Inthis case:

MechanismId = 110MainMechanismId = 107Name = 'Structure overtopping 2017'

3 SubMechanisms: All submechanisms are listed here. Note that no connection is made toa MechanismId, because a submechanism can be part of more than one mechanism. Forthis mechanism 3 submechanisms are relevant: Z11, Z12 and Z13.

SubMechanismId = 421Name = "Structure 2017 Z11"DllName = "structuresOvertopping2017.dll"

56 of 106 Deltares


ZValueSubroutine = "GetZValueZ11"InitializationSubroutine = "InitializeZ11"FinalizationSubroutine = ""

SubMechanismId = 422Name = "Structure 2017 Z12"DllName = "structuresOvertopping2017.dll"ZValueSubroutine = "GetZValueZ12"InitializationSubroutine = "InitializeZ12"FinalizationSubroutine = ""

SubMechanismId = 423Name = "Structure 2017 Z13"DllName = "structuresOvertopping2017.dll"ZValueSubroutine = "GetZValueZ13"InitializationSubroutine = "InitializeZ13"FinalizationSubroutine = ""

In this configuration, a dll with the name structuresOvertopping2017.dll has to beplaced alongside the Hydra-Ring executable and dll’s. This dll has to export the functionsGetZValueZ11, InitializeZ11, GetZValueZ12, InitializeZ12, GetZValueZ13 andInitializeZ13. The configuration database connects the required submechanism func-tions to the dll-functions. The field ZValueSubroutine is required.The fields InitializationSubroutine and FinalizationSubroutine are not requiredand can be omitted. As is the case with these submechanisms, where the field namedFinalizationSubroutine is not specified.

4 SubMechanismsModels: Sometimes a submechanism can be configured with optionalmode types. E.g. in the previous version of the Z11 submechanism a model choiceof "Shields" or "Direct Input" could be specified. These model types can be added asrecords in this table. The current submechanisms of this mechanism do not have sub-mechanism models. The submechanism model has to be applied in the project database.In that database a table SectionSubMechanismModels is available where a submecha-nismmodel can be specified for a specific section/submechanism combination.

5 Variables: Each submechanism uses a set of strength stochasts. These stochasts arespecified in this table. All stochasts for all submechanism should be contained in the table.An example of a variable for the submechanism Z11 is:

VariableId = 20SequenceNumber = 20Name = "Uncertainty in bottom level"

6 SubMechanismVariables: This table specifies which variables are relevant for each com-bination of Submechanism/SubmechanismModel. If SubmechanismModel = -1 then thevariable is used for all SubMechanismModels. E.g. for submechanism Z11 (SubMechanismId= 421) the variables with the following VariableIds are relevant: 20, 21, 23, 58, 59, 60, 61,62, 103, 104, 106.

7 PreparatorySubMechanisms: This is a special feature that is only used for the entryMainMechanism "Slope Instability". There a submechamism calculation has to be per-formed befor the real submechanism calculation. In the case of Slope instability the calcu-lation of the submechanism with the SubMechanismId = 205 has to be performed beforethe calculation of the actual submechanism with the SubMechanismId = 206.

8 FaultTreeModels: In this table the available fault trees are specified. A mechanismcan have more than one fault tree. Each fault tree is defined with FaultTreeModelId.In the case of this submechanism there are four available fault trees. These have theFaultTreeModelIds 4401, 4402, 4403 and 4404. In the project database you haveto specify which fault tree should be applied for a section. This is done in the table

Deltares 57 of 106


SectionFaultTreeModels where for either a specific section or mechanism combina-tion a FaultTreeModelId can be specified.

9 FaultTreeModelSubMechanisms: This table lists which submechanisms are part of aspecific FaultTreeModel. If a FaultTreeModel should at least contain one submecha-nism. If a FaultTreeModel contains more than one submechanism than a fault tree def-inition has to be defined in the table "FaultTree". If a FaultTreeModel contains only onesubmechanism then the fault tree is just that submechanism. In this case there is no ac-tual fault tree (with branches). E.g. in this mechanism FaultTreeModel = 4401 containsonly one submechanism Z11 (SubmechanismId = 421) and FaultTreeModel = 4404contains three submechanisms: Z11 (SubmechanismId = 421), Z12 (SubmechanismId= 422) and Z13 (SubmechanismId = 423)

10 FaultTree: As mentioned above, if a FaultTreeModel contains more than one sub-mechanism than the fault tree definition has to be defined in the table "FaultTree". In thiscase the fault tree table contains two records for the FaultTreeModelId = 4404:

FaultTreeId = "27"FaultTreeModelId = "4404"SubMechanismId1 = "421"SubMechanismId2 = "422"FaultTreeId1 = "0" (0 means that it is not used)FaultTreeId2 = "0" (0 means that it is not used)SequenceNumber = "1" (not used)AndOr = "1" (1 = and, 2 = or)Name = "Structure overtopping 2017" (not used)

FaultTreeId = "28"FaultTreeModelId = "4404"SubMechanismId1 = "423"SubMechanismId2 = "0" (0 means that it is not used)FaultTreeId1 = "0" (0 means that it is not used)FaultTreeId2 = "27"SequenceNumber = "1" (not used)AndOr = "2" (1 = and, 2 = or)Name = "Structure overtopping 2017" (not used)

This definition of the fault tree is the definition for the fault tree as is shown in Figure 3.13.

The workflow described above shows that the coupling of new failure mechanisms is achiev-able. The coupling might be extensive, in terms of IDs and numbers, as is the elaboratedexample. It is for this reason that one of the most laborious examples is taken to display theworkflow of the coupling.

58 of 106 Deltares


3.5 Failure mechanisms with preparatory calculations

Some failure mechanisms cannot handle variations in all stochasts, for a diversity of reasons.Sometimes, this leads to numerical instabilities; in other cases, the data flow does not fit thearchitecture of the computational kernel, or in other cases, the computational runtimes wouldbecome too large. In case of numerical instability, non-smooth or, much worse, discontinuitiesin the failure mechanism description may hamper, or even spoil, the course of the compu-tation. In this section, the implemented algorithm for this purpose (shown in Figure 3.14) isdescribed.

Figure 3.14: The implementation algorithm for failure mechanisms running on prepatorycalls, as is the failure mechanism macrostability.

The numeric instability could be due to a varying water level. Keeping the water level at a fixedvalue leads to continuous Z-values (i.e. limit state evaluation values) and a stable calculationfor the failure mechanisms considered.

Deltares 59 of 106


Another difficulty could be a failure mechanism which contains a varying, unlimited number ofrandom variables. This happens when stochasts are defined on soil layers, where the numberos soil layers is unlimited. For example, cohesion and friction angle are defined per soil layer.An example of such a failure mechanism is macrostability.

Since a varying water level causes numeric instability, the water level is fixed and then thedesign point is determined. This is repeated for several water levels and then these designpoints are combined. This combination is perfomed as a separate failure mechanism, bywhich the Z-value is achieved by interpolating between the design points.

The unlimited number of stochastic variables is reduced by combining them after the calcu-lation with the fixed water level. Per parameter type these variables are combined over allsoil layers (the new squared alpha is the sum of the squared individual alpha values). This isimplemented as shown in Figure 3.14.

The implementation of the blocks in Figure 3.14 is as follows:

1 Obtain fixed water levels: set the initial fixed water levels. In case of macrostability, this isuser input.

2 Request random variables: get all random variables from the model.3 Prepare input set: any operations before the next step can be performed. In case of

macrostability, determine the sliding plane for all diameter values and store this slidingplane.

4 Calculate design point: calculate the design only for the given random variables. In caseof macrostability, only calculate the safety factor for the sliding plance calculated earlier.The limit state function value is the safety factor times a model factor smaller than 1.

5 Condense design point: redefine the design points in such a way that they are definedfor stochasts in the configuration database. In case of macrostability, per parameter, theα-values defined on different soil layers are squared summed.

6 Probabilistic analysis: apply the usual probabilistic analysis.7 Determine the limit state function value: compute the Z-value by interpolation from the

stored design points per water level.8 Get the waterlevel from the design point: get the parameter value from the design point.

In case of water levels per wind direction, take the wind direction that contributes the mostto the final result.

9 Determine if the design point is sufficient: it is sufficient if the water level in the designpoint differs less than a specified level.

3.6 Interface with the User Interface

Hydra-Ring is the computational kernel underneath the User Interface Ringtoets. The userinserts the relevant data in the Ringtoets shell. These relevant data should be passed onto the computational kernel. After the execution of a computation, the outcomes should be-come available for the user through the User Interface. This section deals on the associatedcommunication aspects, based on the conceptual scheme shown in Figure 3.15.

3.6.1 Input from Ringtoets to Hydra-Ring

As soon as the user has inserted the relevant data in the user interface, then a probabilis-tic computation can be conducted by Ringtoets through Hydra-Ring. The data visualized inthe user interface are stored in the PD, an abbreviation for Project Database. The projectdatabase serves as direct input database for Hydra-Ring and is further described in sec-tion 4.3.

60 of 106 Deltares


Figure 3.15: Data interface between Ringtoets and Hydra-Ring (the two blue boxes). Thered cylinders present databases of sqlite-type. The square gray boxespresent ascii-type files. ‘PD’ stands for Project Database, ‘CD’ standsfor Configuration Database, ‘HLCD’ stands for Hydraulic Load ConfigurationDatabase and ‘HRD’ stands for Hydraulic Region Database.

3.6.2 Input from other sources

Apart from input to Hydra-Ring from Ringtoets, three other sources provide essential infor-mation for Hydra-Ring. Firstly, the CD, which is the Configuration Database; secondly, theHLCD, which is the Hydraulic Load Configuration Database; and thirdly, the HRD, which is theHydraulic Region Database. These databases, respectively further described in section 4.4,section 4.5 and section 4.6, are not manipulated by Ringtoets in any way: these databasescontain fixed data, and are supposed not to be manipulated by the user in any way.

3.6.3 Output from Hydra-Ring to Ringtoets

As soon as the probabilistic computation has started, Hydra-Ring commences producing out-put data. The output is captured in three entities: the project database of sqlite-type, anascii-type input file and an ascii-type output file. Ringtoets must be able to read theseoutput files as input files for its own further purposes.

The project database

Obviously, already before having started the Hydra-Ring computation, the project database(PD) exists since it contains the essential input information for a probabilistic computation.When a computation ends, the output is written to the project database through appendingthe output to the input. In the end, the project database contains both the input and the output.As output, the project database contains failure probabilities and design points (as α-values).

Deltares 61 of 106


The input file

The input file contains the collection of subsets of the overall input as present in the PD, CD,HLCD and HRD, necessary to execute a specific computation at a specific location. The inputfile is generated for a certain location and certain mechanism. The input log file is basicallyan echo of the information Hydra-Ring needs to know for the probabilistic computation underconsideration. Figure 3.16 provides a snapshot of an example input log file.

Figure 3.16: Snapshot of an example ascii-type input log file.

The core information of the input log file comprises:

� the name and the version of the executable,� the date and time of the computation execution,� the specification of the location and the mechanisms under consideration,� the used computational settings,� the dyke profile as well as the variable settings,� the statistical settings as well as load uncertainties data,� the lookup table of the local hydraulic load as a function of the basic random variables.

Through this input log file, Hydra-Ring always provides a backdrop of the output resultsgained. In this way, the nature of the outcomes can always be put in the perspective ofthe user’s choices. Moreover, the consistency between the output and the input can alwaysbe reconstructed.

The output file

The output log file displays the intermediate output data obtained with Hydra-Ring along thecourse of the computation. The course of the computation is discussed in section 2.2.1 for theFBC-scheme, in section 2.2.2 for the NTI scheme and in section 2.2.3 for the APT-scheme. Asnapshot of an example output log file is shown in Figure 3.17.

In Figure 3.17, multiple square boxes are drawn. The red box depicts the strength variablenames; the language in which these names are provided can either be Dutch (through theoption NL) or English (through the option UK). The blue boxes depict general names, alwaysgiven in English.

62 of 106 Deltares


Figure 3.17: Snapshot of an example ascii-type output log file. The red box depictsthe strength variable names (in either Dutch (language option NL) or En-glish (language option UK). The blue boxes depicts names that are given inEnglish.

As an example, the output log file for a water level computation is discussed. Suppose, theexceedance probability of a particular water level in Lake IJssel is to be computed by Hydra-Ring, then the sequence of the output log file is as follows:

Submechanism = Reference water level for Wind direction = 1Status = Mechanisme given wind directionStatus = Upscaled to dike section given wind direction

Submechanism = Reference water level for Wind direction = 2Status = Mechanisme given wind directionStatus = Upscaled to dike section given wind direction

[... similar for other wind directions ...]Submechanism = Reference water level for Wind direction = 16

Status = Mechanisme given wind directionStatus = Upscaled to dike section given wind direction

Status = Upscaled to largest block duration for Wind direction = 1Status = Upscaled to largest block duration for Wind direction = 2[... similar for other wind directions ...]Status = Upscaled to largest block duration for Wind direction = 16Status = Dike section and wind direction for Wind direction = 1Status = Dike section and wind direction for Wind direction = 2[... similar for other wind directions ...]Status = Dike section and wind direction for Wind direction = 16Status = Combined over wind directionsStatus = Final result for calculation period

The output logging is by far the simplest for a water level computation, since no failure treeis active. For other mechanisms, the output logging is more complex. As an example, thesequence of the output logging is shown for overtopping (dykes):

Submechanism = Overtopping RTO for Wind direction 1

Deltares 63 of 106


Submechanism = Overflow for Wind direction 1Status = Fault tree combination 1 for Wind direction 1Status = Mechanisme given wind direction for Wind direction 1Status = Upscaled to dike section given wind direction for Wind direction 1[... repetition of these steps for all wind directions 2 up to 15 ...]Submechanism = Overtopping RTO for Wind direction 16Submechanism = Overflow for Wind direction 16Status = Fault tree combination 1 for Wind direction 16Status = Mechanisme given wind direction for Wind direction 16Status = Upscaled to dike section given wind direction for Wind direction 16Status = Upscaled to largest block duration for Wind direction 1[... repetition for all wind directions 2 up to 15 ...]Status = Upscaled to largest block duration for Wind direction 16Status = Dike section and wind direction for Wind direction 1[... repetition for all wind directions 2 up to 15 ...]Status = Dike section and wind direction for Wind direction 16Status = Combined over wind directions, returns the Governing wind directionStatus = Final result for calculation period

This example only takes into account the variation of the wind direction, which is ubiquitousin probabilistic computations. Depending on the water system and computational techniqueunder consideration, the complexity of the output logging might increase due to additionalinformation on a potential closure regime and activation of another computational technique(in case of hybrid methods such as FDIR). Consider Figure 3.18 for a snapshot of the outputlog file. In this figure, the results for a certain wind directions are shown for the mechanismovertopping/overflow for dykes.

Figure 3.18: Snapshot of the logging of the design point for an example computation forovertopping/overflow for dykes.

64 of 106 Deltares


The design point can be captured from the output log file. It is important to realize that thedesign point is only defined on the level of an individual limit state function; for instance, onefor overtopping and one for overflow. The design point is provided for each wind direction andclosure situation. Often, the most relevant design point is the design point for the governingwind direction. As an example, consider the design point logging as shown in Figure 3.18.

In Figure 3.18, the wind direction with ID 13 is shown; suppose that this wind direction is gov-erning for this computation. The values in the column denoted by X provides the actual designpoint in physical space (the X-space) rather than in the U -space, which is conventional forprobabilistic computations. The U -space is standard normally distributed.

3.7 Aspects of malfunctioning

The aspects of malfunctioning are related to functioning of Hydra-Ring as soon as unex-pected, undesired behavior occurs. In such cases, proper error handling should be deployed.The design of the error handling is sketched in Figure 3.19. The scheme incorporates thezrFunc-part already shown in Figure 2.6.

Figure 3.19: Interface with error messaging components.

Figure 3.19 displays the feedback library in the top of the scheme, as the library of top im-portance. Within the feedback library, the general procedures for error handling are compiledin order to meet the modularity requirements. The evaluation of the limit state function isplaced in the center of the image: zrFunc. This functionality consists of three parts (refer toFigure 2.6):

� the routine calculateHydraulicStat for the evaluation of the statistics,� the routine calculateHydraulicLoad for the evaluation of the hydraulic load,� the routine that connects with the dynamic link library (dll) of the specific failure mecha-

nism.

Deltares 65 of 106


The evaluation of the limit state function is always connected to the execution of a probabilisticcomputation procedure (like FORM, DSFI, etc.). These probabilistic routines are part of theprobabilistic library.

The error handling fits into this picture in two ways:

� direct calls to the feedback library are only done directly from the probabilistic libary andfrom the routines to evaluate the statistics and the hydraulics,

� from the failure mechanisms part, error flags, in case of no errors) are used for the errorhandling: either from the failure mechanisms dll an error flag is sent to the calling sub-routine, or an error flag is sent from the central limit state evaluation function to the calingprobabilistic subroutine.

66 of 106 Deltares

4 Database design description

Besides the computational kernel itself and the fundamental software components it runs on,e.g. failure mechanisms, the software depends heavily on the essential information stored inthe four databases. As already highlighted, the design provides in a project database (PD), aconfiguration database (CD), a hydraulic load configuration database (HLCD) and a hydraulicregion database (HRD). The design of these databases is described in this chapter.

4.1 Purpose

Whereas in the previous chapter the strict modularity of software components was introduced,the current chapter has addressed the database design with the same purpose: strict mod-ularity. For the databases, this means that each database has its own singular reason forbeing. Like depicted in section 3.3, it should be possible for an advanced user to extendthe functionality of the software without the need to change the source code, but truly fromdatabases.

As a consequence, the functionality of each of the four database is unique as follows:

� the project database (PD): the input and results is contained in one project database, inorder to assure consistency between input and output.

� the configuration database (CD): this database will contain settings for configuring theuser interface and the computational core, without the need to change the software. Con-figuration will simplify for example the addition or modification of models, or changing thedefault values for certain input parameters.

� the hydraulic load configuration database (HLCD): the hydrodynamic location configura-tion database contains firstly a list of output locations for all regions together, allowingfor linking via the user-interface of a defence section location to an output location in acertain hydrodynamic database per region (HRD). The hydraulic configuration databasecontains secondly the statistical configuration options for the stochastic load variables, forall regions together.

� the hydraulic region database (HRD): the hydrodynamic data includes the water level, thesignificant wave height and other hydraulic parameters for each location, as a function ofthe river discharge, the sea level, the wind direction and the wind velocity. The location atthe river axis or at the toe of the flood defence is defined by a location type and number.

In the following, the PD is described in section 4.3, the CD is described in section 4.4, theHLCD is described in section 4.5 and the HRD is described in section 4.6. For the descriptionof the routines to generate the HLCD database and the HRD database, the reader is referredto the Database Functional Design, by Keppel (2014). The generation of the PD and CD isthe responsibility of Hydra-Ring, and is directly achieved by associated sql-scripts.

Deltares 67 of 106


Figure 4.1: Visualization of the datamodel from a dyke section perspective.

4.2 Design conventions

The most relevant design convention that holds for the database is the datamodel introducedin the Functional Design Deltares (2016a). For the data structure of the multiple levels,see Figure 4.1. The defined data structure is reflected in many components of the variousdatabases.

The database format that is used is SQLite. SQLite is an in-process library that implements aself-contained, serverless, zero-configuration, transactional SQL database engine. The codefor SQLite is in the public domain and is thus free for use for any purpose, commercial orprivate.

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLitedoes not have a separate server process. SQLite reads and writes directly to ordinary diskfiles. A complete SQL database with multiple tables, indices, triggers, and views, is containedin a single disk file. There are no size restrictions. In Figure D.1, the relation between mainmechanisms, mechanisms, submechanisms and fault trees is visualized in a class diagram.

4.3 The project database (PD)

The most important fields of the project database are described in more detail in § 4.3.1 up to§ 4.3.6. Less important fields are very briefly described in § 4.3.7 up to § 4.3.21. The projectdatabase contains both the input data of a project and the output data. The output data ofresults of a reliability analysis for a single element are stored and used, on its turn, as inputfor the ring computation executable. Also see the full list in section B.1. The associated classdiagram visualized in Figure D.2.

68 of 106 Deltares

Database design description

4.3.1 The field HydraulicModels

Within the field HydraulicModels, the following input can be set (in this sequence):

� TimeIntegrationSchemeID – option 1 is FBC, option 2 is APT and option 3 is NTI.� UncertaintiesID – option 0 comprises running Hydra-Ring without uncertainties, whereas

option 1 comprises running Hydra-Ring with uncertainties. With options 2 and 3, the usercan use either model uncertainties or statistical uncertainties, respectively.

� DataSetName – The name of the dataset, typically 'WTI 2017'. As a reference 'TMR2006' can be used, but be aware of the possibility that in the two sets other station loca-tions are provided.

Typically, the following input is set:

INSERT INTO [HydraulicModels] VALUES (1, 0, 'WTI 2017');

4.3.2 The field Sections

Within the field Sections, the following input can be set (in this sequence):

� SectionId – An integer that is a sequence number for the location of interest.� PresentationId – An integer with value 1, by default. Only relevant in case of the com-

bination of multiple dyke sections.� MainMechanismId – An integer with value 1, by default. Only relevant in case of the

combination of multiple dyke sections. For a full list of ID’s, see section 4.4.� Name – A string with the short name of the location. This location name is used in the

name of the input file and the output file.� Description – A string that contains a description of the short name (previous field).� RingCoordinateBegin – A real number that provides the one end of the dyke section

stretch. This field is not in use currently; it could be used for communication with the UserInterface.

� RingCoordinateEnd – A real number that provides the other end of the dyke sectionstretch. This field is not in use currently; it could be used for communication with the UserInterface.

� XCoordinate – The location of the cross-section (i.e. point within the dyke stretch) eastof Paris (in meters).

� YCoordinate – The location of the cross-section (i.e. point within the dyke stretch) northof Paris (in meters).

� StationId1 – The dyke location must be connected with a station in the HRD for whichhydraulic boundary conditions (lookup-tables) are available. Each station has a uniqueindex. The indices can be viewed in the HLCD (by means of the SQLite Manager add-onin Mozilla Firefox). Typically, the station nearest to the dyke cross-section is selected.

� StationId2 – The user is able to select two stations for the dyke cross-section. In sucha case, Hydra-Ring interpolates the results from the lookup-tables.

� Relative – This real number represents a percentage for the weighting of the two hy-draulic stations selected. Typically, one single station is selected, such that the secondstation is set equal to the first station with a weighting percentage of 100%.

� Normal – The angle of the straight line perpendicular to the dyke stretch at the location ofthe dyke cross-sections (with respect to the north).

� Length – A real number that represents the length of the dyke section. Hydra-Ring appliesa so-called length-effect over the full length of the dyke section, in order to extend thefailure probability at a particular location to a failure probability valid for the full length ofthe dyke stretch.

Deltares 69 of 106



INSERT INTO [Sections] VALUES ( 35, 1, 1, 'Cornwerd', 'Cornwerd', 153122,565937, 153122, 565937, 700003, 700003, 100, 210, 1);

4.3.3 The field DesignTables

The field DesignTables enables the definition of the numerical settings. The associatedclass diagram is visualized in Figure D.3. Within the field DesignTables, the following inputcan be set (in this sequence):

� SectionId – An integer that couples the location ID to specific settings for the type ofcalculation.

� MechanismId – An integer that couples the index of the location to the index of the failuremechanism. For instance, 1 represents a design water level computation, 11 is the indexto compute marginal wave statistics, 3 is the index for the Q-variant (for revetments) and101 represents an overtopping computation. For a full list, see section 4.4.

� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� Method – The type of computation (regular or design or table).

� 1 - Compute exceedance probability,� 2 - Iterate towards a target probability, provided as reliability index,� 3 - Repetition of a type-1 calculation that produces a table of exceedance probabilities

in an additional output file designTable.txt,� 6 - Design computation that iterates to a given reliability index β,� 7 - Modified design computation for the Q-variant,� 8 - Type-7 calculation with automatic definition of upper and lower limits,� 9 - Design computation for water levels with automatic definition of upper and lower

limits,

� VariableId – An integer that represents the ID of the variable that is considered. Forinstance, the water level in case of a straightforward design water level computation.

� LoadVariableId – Not relevant, always set to NULL.� TableMin – If the user chooses a type-3 computation (see Method), then a table of failure

probabilities is produced. This particular input field sets the lower limit for the randomvariable value under consideration.

� TableMax – If the user chooses a type-3 computation (see Method), then a table of failureprobabilities is produced. This particular input field sets the upper limit for the randomvariable value under consideration.

� TableStepSize – Related to the previous two fields: for a type-3 computation, a batchof type-1 computations is launched for the values TableMin to TableMax in steps ofTableStepSize.

� ValueMin – If the user chooses a type-2 computation (see Method), then Hydra-Ringiterates towards the target probability. The first iteration is done for the value specifiedas ValueMin. A value for this entry close to the expected outcome is desired but notnecessary; it might speed up the computation.

� ValueMax – If the user chooses a type-2 computation (see Method), then Hydra-Ringiterates towards the target probability. The second iteration is done for the value specifiedas ValueMax. A value for this entry close to the expected outcome is desired but notnecessary; it might speed up the computation.

� Beta – If the user chooses a type-2 computation (see Method), then a target reliabilityindex should be specified. Recall that Pf = Φ(−β).


70 of 106 Deltares


INSERT INTO [DesignTables] VALUES ( 35, 101, 1, 1, 1, 1, NULL, 2.0, 5.5,0.1, 2.0, 5.5, 3.29053 );

4.3.4 The field Numerics

Within the field Numerics, the following input can be set (in this sequence):


� MechanismId – An integer that couples the index of the location to the index of the failuremechanism. For instance, 1 represents a design water level computation, 11 is the indexto compute marginal wave statistics, 3 is the index for the Q-variant (for revetments) and101 represents an overtopping computation.

� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� SubMechanismId – Its relevance depends on the choice for MechanismId. This coupling

between MechanismId and SubMechanismId is configured within the Hydra-Ring sourcecode. In this memo, no general description is given. In § 4.4, the necessary information isprovided for the mechanisms relevant for the derivation of probabilistic hydraulic boundaryconditions.

� Method – Through this integer value, the computational technique is assigned:

� 1 - method FORM (First Order Reliability Method),� 3 - method CRMC (Crude Monte Carlo),� 4 - method DIRS (Directional Sampling),� 5 - method NINT (Numerical Integration),� 6 - method IMPS (Importance Sampling),� 11 - hybrid method FDIR: FORM in first instance, DIRS in case of no convergence,� 12 - hybrid method DSFI: DIRS in any case, but FORM for the design point,� 13 - hybrid method CMFI: CRMC in any case, but FORM for the design point,� 14 - hybrid method ISFI: IMPS in any case, but FORM for the design point.

� FormStartMethod – FORM is an iterative method that needs a set of values as startingpoint. If Method = 1 is chosen, the user is to specify a starting method to define thestarting point. Remark that the startvalues are defined in ’standard normal distribution’space (referred to as U -space). The following options are provided:

� 1 - value 0 for all random variables (the origin of the U -space),� 2 - value 1 for all random variables,� 3 - user specified vector,� 4 - automatically computed by means of a ray search (recommended),� 5 - automatically computed by means of a sphere search,� 6 - an equivalent of startmethod 4 but with speed-up,� 7 - an equivalent of startmethod 5 but with speed-up,� 8 - a modification to startmethod 4 to deal with slowly varying load random variables

(only applicable for load systems with different time scales for load variables).

� FormNumberOfIterations – FORM is an iterative method. The user can specify a max-imum number of iterations. If no convergence is attained within the specified numberof iterations, Hydra-Ring just returns the result after this number of iterations under thedisclaimer WARNING: NO CONVERGENCE FOR THIS SUBMECHANISM.

� FormRelaxationFactor – Technical parameter: prescribes a certain relaxation towardsthe design point. For further information, see see Deltares (2016c).

� FormEpsBeta – A FORM computation has three convergence criteria; this εβ fixes one ofthem. For further information, see Deltares (2016c).

� FormEpsHOH – A FORM computation has three convergence criteria; this εHOH fixes one

Deltares 71 of 106


of them. For further information, see Deltares (2016c).� FormEpsZFunc – A FORM computation has three convergence criteria; this εZ fixes one

of them. For further information, see Deltares (2016c).� DsStartMethod – This integer value determines the way random numbers are generated.

The option 0 couples the approach to the time (fully random). The option 1 uses a fixedseed (recommended).

� DsIterationmethod – Not relevant, and moreover not active. Fixed to the value 1.� DsMinNumberOfIterations – The method DIRS runs until a break-off criterium is reached.

The present entry prescribes the minimum number of used samples.� DsMaxNumberOfIterations – The method DIRS runs until a break-off criterium is reached.

The present entry prescribes the maximum number of used samples.� DsVarCoefficient – The break-off criterium can be prescribed as a variation coefficient.

This variation coefficient can be inserted for this entry (by default 0.1).� NiUMin – The method NINT deployes a uniform grid in U -space. Each discrete element

has equal size in each dimension (spanned by the number of random variables). Thisentry defines the lower limit.

� NiUMax – The method NINT deployes a uniform grid in U -space. Each discrete elementhas equal size in each dimension (spanned by the number of random variables). Thisentry defines the upper limit.

� NiNumberSteps – The method NINT deployes a uniform grid in U -space. Each discreteelement has equal size in each dimension (spanned by the number of random variables).This entry defines the number of discrete elements from the lower limit to the upper limit.

As an example for overtopping (dykes), typically the following input is set (notice that twosubmechanisms are present):

INSERT INTO [Numerics] VALUES ( 35, 101, 1, 1, 102, 1, 4, 50, 0.15, 0.01,0.01, 0.01, 2, 1, 10000, 20000, 0.1, -6, 6, 25 ); �� OvertoppingRTO;

INSERT INTO [Numerics] VALUES ( 35, 101, 1, 1, 103, 1, 4, 50, 0.15, 0.01,0.01, 0.01, 2, 1, 10000, 20000, 0.1, -6, 6, 25 ); �� Overflow;

4.3.5 The field VariableDatas

The statistical information of the random variables related to the strength of the flood de-fence can be set in the field VariableDatas. The relation of this field to other mecha-nism related fields is visualized by means of a class diagram in Figure D.5. Within the fieldVariableDatas, the following input can be set (in this sequence):


� MechanismId – An integer that couples the index of the location to the index of the failuremechanism. For instance, 1 represents a design water level computation, 11 is the indexto compute marginal wave statistics, 3 is the index for the Q-variant (for revetments) and101 represents an overtopping computation.

� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� VariableId – An integer that represents the ID of the variable that is considered. For

instance, the water level in case of a straightforward design water level computation.� Value – The considered value for the random variable VariableId.� DistributionType – The probability distribution type of the random variable VariableId.

The most important ones are:

� 0 - the variable is not random, but deterministic, with a value assigned through Value,

72 of 106 Deltares


� 2 - the variable has a normal distribution,� 4 - the variable has a lognormal distribution.� 19 - the variable has a truncated normal distribution.

� Parameter1 – If the variable is random, then the mean value is inserted through this entry.� Parameter2 – A real number that represents the standard deviation.� Parameter3 – A real number that represents a third input parameter. This number is used

for prescribing the shift, in case of a shifted lognormal distribution, or the minimum valuein case of truncated normal.

� Parameter4 – A real number that represents a fourth input parameter. In case of trun-cated normal, the maximum value.

� DeviationType – The random nature can be assigned through either a standard devia-tion or a coefficient of variation. If DeviationType = 1, then the standard deviation isused; if DeviationType = 0, then the coefficient of variation is used.

� CoefficientOfVariation – A real number that represents the coefficient of variation.� CorrelationLength – The correlation length is variable-specific and is prescribed by

experts on the specific field of the failure mechanism under consideration.

Typically, the following input is set for one single variable, in this case the dyke height (normaldistribution with µ = 3.95 m+NAP and σ = 0.5 m):

INSERT INTO [VariableDatas] VALUES ( 35, 101, 1, 1, 1, 0.0, 2, 3.950, 0.50,NULL, NULL, 1, 0.00, 300 ); � Dyke height;

Important note: when a lognormal distribution is used, then the mean and standard deviationare interpreted as the mean and standard deviation of the actual lognormal distribution ratherthan on the underlying normal distribution.With truncated normal, the mean and standard deviation are interpreted as the mean andstandard deviation of the underlying normal distribution.

4.3.6 The field CalculationProfiles

A dyke profile can be inserted in extreme detail. The overtopping module, however, only usesa schematized variant of it. The detailedly described profile can be inserted in the tab fieldProfiles. The schematized profile (more interesting than the raw profile data) is to be set inthe tab field CalculationProfiles.

Within the field CalculationProfiles, the following input can be set (in this sequence):


� SequenceNumber – An integer that is interpreted as sequence number of the profile-pointID.

� XCoordinate – The lateral coordinate of the dyke profile point.� ZCoordinate – The vertical coordinate of the dyke profile point.� Roughness – For each profile point, a reduction factor γf (see TAW (2002) for the defini-

tion). By default, the value is 1.0 (no reduction due to bed friction).


INSERT INTO [CalculationProfiles] VALUES (35, 1, 0.000, -4.000, 1.0);

INSERT INTO [CalculationProfiles] VALUES (35, 2, 16.780, 3.390, 1.0);

Deltares 73 of 106


At this point, the most important tab fields have been described. In the next subsections, theless important fields are described, be it in much less detail.

4.3.7 The field SectionFaultTreeModels

The information in this line is fixed for each failure mechanism. Each failure mechanism has itsown configuration, not to be changed by the user. Within the field SectionFaultTreeModels,the following input can be set (in this sequence):


� MechanismId – An integer that couples the index of the location to the index of the failuremechanism.

� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� FaultTreeModelId – Choice out of the prefabricated fault tree configurations.

4.3.8 The field SectionSubMechanismModels

Within the field SectionSubMechanismModels, the following input can be set (in this se-quence):


� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� SubMechanismId – An index to uniquely identify the submechanism, relevant for the con-

figuration of the fault tree.� SubMechanismModelId – An index to uniquely identify a specific model choice relevant

for a certain mechanism.

4.3.9 The field Fetches

In earlier safety assessments, the user needed to prescribe fetches to compute waveheightsand wave periods in river areas. In the WTI2017, this need has been removed, since wave-heights and wave periods will be provided in the HRD-lookup-tables for each water system.Hence, this field is practically deprecated. Within the field Fetches, the following input can beset (in this sequence):



� WindDirectionId – An integer that indicates the wind direction (depending on the num-ber of wind directions in each water system).

� SequenceNumber – An integer that indicates the sequence of the bathymetry in front ofthe dyke cross-section.

� Length – The length of the fetch.� Bottom – Description of the bathymetry (bed level with respect to NAP).

The relevant connections of this field with other wind wave related fields are visualized inFigure D.4.

74 of 106 Deltares


4.3.10 The field AreaPoints

In this tab field, the points which describe the shape of the dyke ring (or section) can beinserted. Within the field AreaPoints, the following input can be set (in this sequence):

� AreaId – The ID of the specific area.� RingCoordinate – The ID of the location within the ring (or stretch).� XCoordinate – The x-coordinate of the location within the ring (or stretch).� YCoordinate – The y-coordinate of the location within the ring (or stretch).

4.3.11 The field PresentationSections

Sections for the presentaton of section results over all failure mechanisms.

Within the field PresentationSections, the following input can be set (in this sequence):

� Name – The name of the presentation section.� Description – The description of the name of the presentation section.� RingCoordinateBegin – Ring coordinate begin of the presentation section.� RingCoordinateEnd – Ring coordinate end of the presentation section.

4.3.12 The field Profiles

This field has a strong link with the field CalculationProfiles (see above). Within the fieldProfiles, the following input can be set (in this sequence):


� SequenceNumber – An integer that is interpreted as sequence number of the profile-pointID.

� XCoordinate – The lateral coordinate of the dyke profile point.� ZCoordinate – The vertical coordinate of the dyke profile point.

4.3.13 The field ForelandModels

Within the field ForelandModels, the following input can be set (in this sequence):



� Model – An integer that indicates the model used for the influence of the foreshore.

The only foreshore model that is supported for WTI2017 is the one with ID 3.

Deltares 75 of 106


4.3.14 The field Forelands

Within the field Forelands, the following input can be set (in this sequence):


� SequenceNumber – An integer that couples the location ID to specific bed level of theforeland at a certain lateral location.

� XCoordinate – Lateral location (in meters) at which the bed level (as part of the foreland)is provided.

� ZCoordinate – The bed level of the foreland at the specific lateral location.

4.3.15 The field ProbabilityAlternatives

Within the field ProbabilityAlternatives, the following input can be set (in this sequence):


� MechanismId – An integer that couples the index to the index of the failure mechanism.� LayerId – An index only relevant for revetment computations.� AlternativeId – An index only relevant for piping computations.� Percentage – Each alternative has been assigned a certain probability of occurence. The

sum of all prescribed percentages (all alternative) should, obviously, sum up to 100%.

4.3.16 The field SetUpHeights

Within the field SetUpHeights, the following input can be set (in this sequence):



� WindDirectionId – The ID of the wind direction for which the setup height is provided.� Height – Additional water level due to setup, given for a certain section, mechanism and

wind direction.

4.3.17 The field CalcWindDirections

Within the field CalcWindDirections, the following input can be set (in this sequence):



� WindDirectionId – The ID of the wind direction which is switched on (value 1, by default)or switched off (value 0).

� isUsed – The actual switch to discriminate between wind directions to be taken into ac-count (value 1, by default) or not to be taken into account (value 0).

This field could be manipulated by the preprocessor to switch off wind directions, as describedin section 2.4.4.

76 of 106 Deltares


4.3.18 The field Swells

Within the field Swells, the following input can be set (in this sequence):



� Height – A value that prescribes the wave height associated with the swell.� Period – A value that prescribes the wave period associated with the swell.

4.3.19 The field WaveReductions

Within the field WaveReductions, the following input can be set (in this sequence):



� WindDirectionId – The ID of the wind direction under consideration for which a separatereduction factor for (only) the wave height can be inserted.

� Factor – The actual value of the reduction of (only) the wave height, for a certain winddirection. The value should be between 0 and 1.

4.3.20 The field Areas

Within the field Areas, the input is not quite relevant and can be kept like this:

� standard: INSERT INTO [Areas] VALUES (1, '1', 'Nederland');

4.3.21 The field Projects

Within the field Projects, the input is not quite relevant and can be kept like this:

� standard: INSERT INTO [Projects] VALUES (1, 'Sprint', 'Hydra-Ring Sprint');

4.3.22 Output fields

As visualized in Figure 3.15, the Project Database is extended with the results of Hydra-Ring,as soon as a probabilistic computation has come to an end. The output results are stored inthe following field:

� the field AlphaResults – containing the influence coefficients α for each variable for eachcomputation that has been executed.

� the field BetaResults – containing the reliability index β for each computation that hasbeen executed.

For computations with preparatory calls (e.g. macrostability), the influence coefficients andthe reliability index are stored for each water level that is specified by the user. The associatedoutput fields are AlphasPerWaterlevel and BetaPerWaterlevel.

Deltares 77 of 106


4.4 The configuration database (CD)

In this section, the fields of the configuration database are explained. The configurationdatabase is part of the artefacts of the Hydra-Ring build and known as config.sqlite.Because of the complexity of the contents of the fields, the actual contents are not discussedthemselves, but rather the rationale behind the fields. The ordering of the documentation ofthe fields follows the ordering most suited for didactical purposes. For this, recall the data-model visualized by Figure 4.1. Also see the full list in section B.2.

4.4.1 The field Variables

The Variables-field is the core of the configuration database. This fields contains all strengthvariables active in Hydra-Ring. For each variable, the information is provided concerning theID, the name, the correlation values ρx, ρt and ρw, the unit and the time scale. The full list isalready documented in the failure mechanisms chapter in Deltares (2016c).

4.4.2 The fields MainMchanisms and Mechanisms

The MainMechanisms comprise the highest level of combination of failure mechanisms. Thefollowing ID’s are supported, and coupled to specific Mechanisms:

� MainMechanismID = 1 is named ‘Verification’, containing:

� MechanismID = 1 representing mechanism ‘Reference water level’,� MechanismID = 2 representing mechanism ‘Load stochastic variable’,� MechanismID = 3 representing mechanism ‘Q-variant’,� MechanismID = 11 representing mechanism ‘WaveCondition’,� MechanismID = 33 representing mechanism ‘Slow stochastic variable’,

� MainMechanismID = 101 is named ‘Overflow and overtopping’, containing one singlemechanism, namely MechanismID = 101 with the name ‘Overflow and overtopping’,

� MainMechanismID = 102 is named ‘Slope instability’, containing one single mechanism,namely MechanismID = 102 with the name ‘Slope instability’,

� MainMechanismID = 103 is named ‘Piping/heave’, containing one single mechanism,namely MechanismID = 103 with the name ‘Piping/heave’,

� MainMechanismID = 201 is named ‘Structure’, containing three mechanisms, namely:

� MechanismID = 110 representing mechanism ‘Structure overtopping 2017’,� MechanismID = 111 representing mechanism ‘Structure not closing 2017’,� MechanismID = 112 representing mechanism ‘Structure constructive failure 2017’,

� MainMechanismID = 301 is named ‘Dune erosion’, containing one single mechanism,namely MechanismID = 108 with the name ‘Dune erosion’.

The rationale behind the field MainMechanism is the clustering of closely correlated randomvariables. For instance, the main mechanism ‘structure’ contains three mechanisms: ‘over-topping’, ‘non-closure’ and ‘constructive failure’. These three mechanisms largely run on thesame variables. The precendence of the combination of these three mechanisms assures asmaller loss of correlation.

Notice that only ID’s larger than 100 for MainMechanisms are taken into account at a com-bination computation. The main mechanisms with ID equal to 1, i.e. ‘verification’, are keptout of consideration. The verification main mechanisms comprise the HR-modules, i.e. thecomputation of marginal water level statistics, marginal wave statistics (both Hs and Tp, orTm−1,0 or another wave period) and the Q-variant.

78 of 106 Deltares


Failure mechanisms for dykes have numbers in the orde of 100, structures in the order of200 and dunes in the order of 300. Notice that the main mechanism ‘revetments’ is not yetpart of the software for WTI2017. This main mechanism ‘revetments’ would comprise themechanisms stone revetments, asphalt revetments and grass revetments. The architectureof the database, as well as the software, is hence already suited to be extended towardsrevetments.

In the field Mechanism, a number is provided under the label StatisticSet; by default, itsvalue is equal to 1. However, for revetments (i.e. Q-variant) this value is 2. This deviationindicates the use of a second statistic set for the Volker statistic set in the tidal Rhine area.

4.4.3 The field SubMechanisms

The key hierarchy is MainMechanism → Mechanism → SubMechanism. In the databasefield SubMechanisms, the specifications are set for each individual limit state function. On thislevel, the name of the dll is provided, as well as the hydraulic load needed to evaluate the limitstate function. In the column named WavePeriodSequence, the type of wave period is given:

� label 3 for Ts, with sequence 3456,� label 4 for Tp, with sequence 4356,� label 5 for Tpm, with sequence 5346,� label 6 for Tm−1,0, with sequence 6345,

in which the sequence is followed in case a certain HRD does not provide in the desiredparameter, obviously using appropriate transformation factors.

4.4.4 The fields SubMechanismModels and SubmechanismVariables

For some submechanisms, it is possible to choose between multiple model options. For in-stance, in case of structures, the type of structure can be specified. Each of such a specifica-tion is provided an ID. The field SubMechanismModels couples the potential submechanismmodels to the associate submechanisms. The options are provided in the failure mechanismchapter of Deltares (2016c) and references therein.

Each submechanism model requires specific variables. In the field SubmechanismVariables,these variables are listed and coupled to the associated submechanism model. If a variableis not particularly linked to a single submechanism model, the variables is specified a -1.

4.4.5 The field FaultTree

The configuration of all fault trees is administrated in the field FaultTree. An example ofsuch a fault tree is provided in Figure 3.13. In a fault tree, the results of the individual limitstate functions (submechanisms) are combined along branches. Each branch of the fault treeis combined pairwise (also described in the failure mechanisms chapter in Deltares (2016c)).

The names and the sequence numbers for the consecutive branches are provided in the table,as well as the specific of the gate-type of the failure branch combination: either AND or OR.The administration of the combinations is directly linked to the SubMechanismID.

Deltares 79 of 106


4.4.6 The fields FaultTreeModels and FaultTreeModelSubMechanisms

Two additional fields are present in the configuration database, dealing with more complexfault tree settings. The FailtTreeModels comprise the two elements of the branch to becombined. For instance, in case of the fault tree provided in Figure 3.13, the red label dis-tinguish the multiple FaultTreeModels. The field FaultTreeModelSubMechanisms coupleseach FaultTreeModelID to a SubMechanismID.

4.4.7 The field PreparatorySubMechanisms

The field PreparatorySubMechanisms lays the connection between the SubMechanismIDsubjected to such a computation and the associated ID of the PreparatorySubMechanismsIDunder consideration. Currently, only macrostability utilizes this option. Hence, the only con-tent of this table is the connection between the entry SubMechanismID = 206 to the entryPreparatorySubMechanismsID = 205.

80 of 106 Deltares


4.5 The hydraulic load configuration database (HLCD)

The hydraulic load configuration database is part of the software delivery and is not supposedto be adapted or manipulated by the user. In this database, the data documented in Chbaband Eilander (2016) and Chbab and Groeneweg (2015) are stored. Since the amount of datatypes in this database, named HLCD.sqlite, is ample, it is not worthwhile to describe eachindividual database field. Hence, only the most relevant database fields are addressed in thissection. Also see the full list in section B.3.

The generation of the HLCD is a complex process. The design of this HLCD is described in adedicated report, by Keppel (2014). Some aspects of the conversion of basic data provided byChbab and Eilander (2016) and Chbab and Groeneweg (2015) by means of the proceduresdescribed by Keppel (2014) to actual input for Hydra-Ring are illustrated in Appendix C.

4.5.1 The field LoadVariables

Whereas all strength variables are listed in config.sqlite, the strength variables are listedin the field LoadVariables in HLCD.sqlite. This field is closely related to a different fieldnamed LoadVariableTypes in which load types as clusters are listed (e.g. just wind speedas clustering of wind speed Deelen, wind speed Schiphol, etc.). For each variable, the in-formation is provided concerning the ID, the name, the correlation values ρx, ρt and ρw, theunit and the time scale. The full list is already document in the hydraulic regions chapter inDeltares (2016c).

4.5.2 The field Locations

The Locations field contains two location ID’s: the LocationID and the HRDLocationID.The latter one is actually used in the database infrastructure, the first one is used as a keyto connect a dyke cross-section to a hydraulic boundary condition location. Recall that eachhydraulic region has a unique ID as well (see Deltares (2016a) and Deltares (2016c), alsosee the Regions field). The region ID and the ID of the HRD location form the locationID through LocationID = RegionID · 105+ HRDLocationID. In combination with the fieldTypesOfHydraulicData, the type of location (either axis and/or shore) can be looked up.

4.5.3 The fields RegionVariables and ResultVariables

For each region, specified in the field Regions, the active random variables are listed. Theseactive random variables form the basic stochastic variables the hydraulic region runs on. Inthis field, the variables are represented by their unique ID’s.

The associated variables that are specified at the dyke locations (hence, different from thebasic random variables) are listed in the field ResultVariables. For the variables specifiedin this field, the results of previously conducted hydraulic computations are provided in theassociated HRD-database.

4.5.4 The field Tracks

Conceptually, for each hydraulic region there exists one unique HRD-database. For somehydraulic regions, the related HRD-database is very large (> 20 GB). In order to enhance theconvenience in use of these database, all the region specific HRD-databases are subdividedin multiple HRD’s. In principle, the level up to which the subdivision is conducted is the tracklevel (traject). The field Tracks is the result of this subdivision and tabulizes the connectionbetween each individual track to a unique HRD-database.

Deltares 81 of 106


4.5.5 The fields Uncertainties and UncertaintyTypes

As mentioned in section 4.5.1, the load variables are listed in the field LoadVariables.A subset of these load variables represent statistical uncertainties additional to the regu-lar load variables. These statistical uncertainties are treated as basic random variables aswell. In the field Uncertainties, each UncertaintyID is coupled to a VariableID and aDistributionType.

The type of the uncertainty is specified in the UncertaintyType. There are four typesof uncertainties supported by Hydra-Ring (in UncertaintyTypes), namely 1 ‘additional’, 2‘multiplicative’, 3 ‘additional and truncated’ and 4 representing the type ‘multiplicative andtruncated’. For further information on their implementation in the source code, see Deltares(2016c).

82 of 106 Deltares


4.6 The hydraulic results database (HRD)

The hydraulic region database contains region-specific data concerning local water levelsand wave parameters. For each hydraulic region, one unique database is provided. Theuniqueness of a hydraulic region is determined by a unique set of statistical descriptions ofthe active random load variables. Because of the large size of the structure of the database,only the most relevant fields are addressed in this section. Also see the full list in section B.4.

The processing of all the hydraulic data is a bulky process. Some basic aspects of the interac-tion with this data collection process with the statistical data collection process are illustratedin Appendix C. The complete list of available hydraulic region databases is provided in ??.

4.6.1 The field HRDLocations

The hydraulic boundary conditions locations are specified in the HRD-database as well as inthe HLCD-database. The field HRDLocations list all the locations and specifies for eachlocation the name, the coordinates and the type (axis, shore, etc.). As a result, a fieldLocationTypes is present in each HRD-database as well as in the single HLCD-database.

4.6.2 The field HRDResultVariables

As a mirror of the equivalent HLCD-data, the list of the result variables in the HRD-databaseare listed in HRDResultVariables. The result variables comprise variables that are a directresult of previously conducted computations with deterministic kernels such as WAQUA andSWAN.

The field HRDResultVariables contains a column named RepairNonDecreasingValues.The values listed in this column are 0 by default. The user can force Hydra-Ring to use mono-tonically developing result variables output series. By switching the 0 into a 1 for a specificvariable, Hydra-Ring corrects for irregularities in the output series as indicatively visualized inFigure 4.2.

Figure 4.2: Schematic image of the modification of data series in order to enforce mono-tonicity of the data series.

Deltares 83 of 106


4.6.3 The field UncertaintyModelFactor

Whereas the statistical uncertainties in the hydraulic load are provided in the HLCD-database,the model uncertainties are registered in the individual HRD-databases. The model uncer-tainties are provided as a mean and a standard deviation for a unique combination of thelocation, the closing situation and the hydraulic load variable under consideration.

84 of 106 Deltares

References

Chbab, H. and D. Eilander, 2016. Basisstochasten WTI-2017. Tech. rep., Deltares, 1209433-012-HYE-0007.

Chbab, H. and J. Groeneweg, 2015. Modelonzekerheid belastingen. Tech. rep., Deltares,1209433-008-HYE-0007.

Deltares, 2011. Review FOTO Hydra-Ring (gespreksverslagen 17 maart en 6 april 2011).Tech. rep., Deltares, 1202575-004-ZWS-0005.

Deltares, 2016a. Hydra-Ring Functional Design. Tech. rep., Deltares, 1230088-021-DSC-0070.

Deltares, 2016b. Hydra-Ring Technical Design. Tech. rep., Deltares, 1230088-021-DSC-0071.

Deltares, 2016c. Hydra-Ring Technical Reference Manual. Tech. rep., Deltares, 1230088-021-DSC-0072.

Deltares, 2016d. Hydra-Ring Test Plan. Tech. rep., Deltares, 1230088-021-DSC-0073.

Deltares, 2016e. Hydra-Ring Validation Document. Tech. rep., Deltares, 1230088-021-DSC-0074.

Keppel, F., 2014. Datamodel HBRDB. Tech. rep., Deltares, 1209432-001-GEO-0003.

Kramer, J., 2016. Software Package: DaF-module, Dam and Foreshore module – FunctionalDesign. Tech. rep., Deltares, 1230095.001.

Markus, A., H. Steenbergen and R. Brinkman, 2011. Hydra-Ring Design Document, version2.2. Tech. rep., Deltares, 1204145-004-ZWS-0003.

Projectbureau VNK, 2009. Van ruwe data tot overstromingsrisico, versie 2.01. Handleiding terbepaling van het overstromingsrisico. Tech. rep., RWS Waterdienst.

Rijkswaterstaat, 2008. Prestatiepeilen Oosterschelde. Tech. rep., Ministerie van Verkeer enWaterstaat, April 24th.

TAW, 2002. Technisch Rapport Golfoploop en Golfoverslag bij Dijken. Tech. rep., TechnischeAdviescommissie voor de Waterkeringen.

Visschedijk, M., 2010. Definitiestudie Hydra-Ring rekenhart voor proefperiode. Tech. rep.,Deltares, 1202575-004.

Deltares 85 of 106


86 of 106 Deltares

A Glossary of terms

In the table below, a glossary of terms and nomenclature is given.

Table A.1: Glossary of terms.

English Dutch DescriptionAlternative Ondergrondscenario Subsoil scenario with certain occurrence proba-

bility, in case of stochastic subsoil modelling.APT APT Arbitrary Point in Time refers to a method of mod-

elling the shape of a temporal discharge wave byintroduction of uniform distributed stochastic timevariable, additional to the stochastic peak value.

Assessment Toets Refers to the assessment of flood defences to de-termine if they comply with legally mandated pro-tection levels during the assessment period.

Assessment waterlevel

Toetspeil Similar to design water level, it is the water level atthe end of the assessment time frame, associatedwith a legally mandated high return period.

Block Blok Refers to the rectangular shape of a temporal pro-cess, such as a discharge wave.

Block duration Blokduur The width (in time) of a temporal process repre-sented by a block.

Characteristic lines Karakteristieke lijnen Lines parallel to the dike, which combine a certaincharacteristic point in different dike cross-section.

Characteristic value Karakteristiekewaarde

Value with a certain exceedance probability

Combining Oprollen Combining failure probabilities for elements withunequal design points, using Hohenbichler.

CRMC CRMC Crude Monte Carlo sampling.Combinationsections

Combinatievakken Dike sections, with a division following fromthe joined mechanism sections, for a semi-probabilistic assessment of combined mecha-nism.

Cross section Doorsnede An infinitesimal point in a dike section at whichfailure probabilities are first computed.

Design point Illustratiepunt,Ontwerppunt

The combination of parameters at failure with thehighest probability. The FORM method linearizesthe Limit State function in this point, after estimat-ing it by a gradient search method.

Design water level MHW, Ontwerppeil Water level at the end of the design life associatedwith a legally mandated high return period.

Detailed assessment Gedetaillerdetoetsing

A semi-probabilistic or probabilistic assessment,based on failure mechanism models requiring de-tailed input.

Dike Dijk A dike as part of a defence system.Dike line Dijklijn The dike location line, usually connecting the

points at the approximate centre of the dike crest.Dike ring Dijkring A dike ring is defined as a single flood cell which

is surrounded by a continuous line of flood de-fences (dikes, dunes, barriers or high ground).

Dike section Dijkvak A length of dike for which strength and load prop-erties are homogeneous.

DIRS DIRS Monte Carlo directional sampling.Discharge Afvoerdebiet The river discharge Q.Discharge peak Afvoerpiek The highest discharge in a modelled discharge

wave.Discharge wave Afvoergolf The assumed development in time of the river dis-

charge during a high water period.(continued on next page)

Deltares 87 of 106


English Dutch Description (continued from previous page)Dune Duin Dune as part of a defence system.Exceedancefrequency curve

Werklijn,Frequentielijn

F (Q).The average number of occurrences perwinter period that the discharge Q exceeds a cer-tain value.

Dagenlijn D(Q). The average number of days per winterperiod that the discharge Q exceeds a certainvalue.

Overschrijdingsduurlijn N(Q) = D(Q)/F (Q). The average duration ofthe period in which Q exceeds a certain value.

DSFI DSFI Directional Sampling with FORM iterations for thedesign point.

Failure Mechanism Faalmechanisme A fundamental process or defect causing fail-ure of the water retaining function. Examplesare: overtopping/overflow, slope instability, pip-ing, revetment failure, dune erosion etc.

Failure probability(FP)

Faalkans On system level, it is the annual probability that aflood defence fails, i.e. that water enters the pro-tected area. Hydra-Ring uses combination tech-niques to combine the FP contributions from sep-arate mechanisms and sections.

Failure mechanismmodel

Faalmechanismemodel A failure mechanism can have more failure mech-anism models. The failure mechanism piping, forexample, can have one or more sub soil models.

FBC FBC Ferry, Borges and Castanheta model for mod-elling temporal processes.

Fetch area Strijklengte The fetch area per wind directing for the develop-ment of wind waves, as input for the Bretschnei-der wave growth model.

File format Bestandsformaat File formats are defined for specific data sets.Flood defence Waterkering A water retaining object (dike, dune, structure),

protecting the hinterland.FORM FORM First Order Reliability Method, determines the so-

called design point and associated FP using iter-ative linearization of the limit state function .

FOS Veiligheidsfactor Abbreviation of Factor of Safety. Ratio betweenthe allowed and actual value of a certaing loadtype.

Heave Opbarsten Mechanism of heave of the cover layer, due to theupward pore pressure in the aquifer underneath.

HLCD database HLCD database Abbreviation of Hydraulic Load ConfigurationDatabase. The hydraulic location and configura-tion database gives an overview of all the outputlocations in the HRD databases for which hydro-dynamic data is given and supplies all the statis-tical data (functions and parameters for distribu-tions and correlations) for all stochastic variablesin all regions, per wind sector.

HRD database HRD database Abbreviation of Hydraulic Region Database. Thehydraulic regional databases supply the outputdata (water level and/or wave parameters) toHydra-Ring as a function of the stochastic loadvariables and the selected output locations (hy-draulic station) in that region.

IMPS IMPS Monte Carlo importance sampling.Hydraulic load Hydraulische

belastingLoad of a construction due to hydrodynamic forc-ing.

Hydrodynamicdatabase

Hydraulischerandvoorwaarden

Database with lookup tables for the hydrodynamicparameters.

(continued on next page)

88 of 106 Deltares

Glossary of terms

English Dutch Description (continued from previous page)Key data Kerngegevens Key data, for setting up a dike schematisation.

Most key data will be imported from existingdatabases, maintained by the water boards.

Layer Bekledingslaag A revetment layer within a (longitudinal) section.Different layer can occur on one cross section.Each layer contains one revetment type.

Length effect Lengte-effect The increase in failure probability that results fromconsidering longer stretches of dike (or dunes).

Limit State Function(LSF)

Grenstoestandsfunctie Describes the interface between failure and non-failure for different combinations of stochastic pa-rameters.

Loop sequence Rekenschema Refers to the sequence of loops (e.g. over winddirections and then over sub-mechanisms) in pro-gramming code.

Mechanism Mechanisme see Failure mechanism.Mechanism section Mechanismevak A stretch of a flood defence with more or less ho-

mogeneous properties and boundary conditionsfor the considered mechanism.

Main mechanism A set of one or more failure mechanisms for whichthe same section division applies. The only setlarger than one is the set of revetment mecha-nisms, consisting of the mechanisms grass, stoneand asphalt.

NTI Numerieketijdsintegratie

Refers to a method of modelling the shape ofa temporal discharge wave with stochastic peakvalue, by discretizing it into sections of width ∆t,and computing the failure probability for each sec-tion. The probability of not failing is then multi-plied across all ∆t, and the failure probability istaken as one minus the product.

NumericalIntegration (NI)

Numerieke integratie Discretizes random variables and for each com-bination computes the probability of occurrenceand subsequently sums over all combinationsthat led to failure. NI, to evaluate the reliability ofa single element is not to be confused with NTI,which accounts for temporal upscaling.

Overflow Overloop Failure mechanism that occurs when the waterlevel is higher than the crest height of the de-fence.

Overtopping Overslag Failure mechanism that occurs when the wavesrun over the crest height of the defence (waterlevel + wave height > crest height).

Piping Piping The mechanism that causes loss of stability byinternal erosion.

Presentation section Presentatievak Sections consisting of one or more combinationsections, for the purpose of presenting the com-bined contribution from different mechanisms incase of a probabilistic analysis.

Probabilistic analysis Probabilistischeanalyse

Probabilistic determination of failure probability,using random distributed variables for load andstrength.

Project database Projectdatabase Database with all project data, except for the re-sults database and hydrodynamic database of theactive project.

Relevance check Relevantietoets Relevance check for a certain failure mechanismfor a certain dike section.

(continued on next page)

Deltares 89 of 106


English Dutch Description (continued from previous page)Revetment Bekleding Revetment of a dike, defined by different zones,

each consisting of a certain revetment type withassociated properties.

RTO RTO Abbreviation for the Dutch name ’Risico-, toets-en ontwerpinstrumentarium’.

Section / Mechanism Vak / Mechanisme Can either be a stretch of a dike or dune, or ahydraulic structure. Sections are user-defined per(main) mechanism.

Section Vak Part of the flood defence system with more or lesshomogeneous load and strength properties.

Semi-probabilisticassessment

Semi-probabilistischetoets

A deterministic assessment, using conservativecharacteristic values for load and strength param-eters, together with partial safety factors. Thesafety factors are calibrated such, that the fail-ure probability will always stay below the allowedvalue.

Simple assessment Eenvoudige toets Simple assessment of a dike section, using fail-ure mechanism models requiring only geometri-cal data.

Slope instability Macro-instabiliteit The mechanism that causes slope shear failureof dike embankments.

Structures Kunstwerken Civil structures built as part of the defence sys-tem.

Submechanism Deelmechanisme A mechanism which only when combined to-gether with another mechanism causes failure.

Tidal period Getijperiode A period of (approximately) one tide, relevant inthe load modelling for an arbitrary discharge waveshape.

Subsoil Ondergrond Subsoil of the dike’s basement.Subsoil alternative Ondergrondscenario See subsoil scenario.Subsoil profile Ondergrondprofiel A sequence of subsoil layers, either one-

dimensional or two-dimensional.Subsoil scenario Ondergrondscenario A subsoil profile with a certain probability of oc-

currence, in case of stochastic suboil modelling.Surface line Dijkoppervlak The surface line of the dike in the cross section,

including the relevant part of the waterbed andthe hinterland.

System architecture Systeemarchitectuur The hardware design of an application.Tab Tabblad Tabs are used to switch between different dialogs.Track Traject Collection of adjacent presentation sections.Tidal period Getijperiode A period of (approximately) one tide, relevant in

the load modelling for an arbitrary discharge waveshape.

Upscaling Opschalen Combining failure probabilities for a number of el-ements (time elements or spatial elements) withequal FP.

90 of 106 Deltares

B Database fields

In this appendix, the full overview is provided of all the databasefields for each of the fourdatabases: the project database (PD), the configuration database (CD), the hydraulic loadconfiguration database (HLCD) and the hydraulic region database (HRD).

B.1 Fields in the project database (PD)

The project database, cf. section 4.3, contains the following fields, in alphabetic ordering:

� Areas� AreaPoints� CalculationProfiles� CalcWindDirections� DesignTables� Fetches� ForelandModels� Forelands� HydraulicModels� Numerics� PresentationSections� ProbabilityAlternatives� Profiles� Projects� Sections� SectionFaultTreeModels� SectionSubMechanismModels� SetUpHeights� Swells� VariableDatas� WaveReductions

The fields in which the output results are stored are, in alphabetic ordering:

� AlphaResults� AlphasPerWaterLevel� BetaPerWaterLevel� BetaResults

B.2 Fields in the configuration database (CD)

The configuration database, cf. section 4.4, contains the following fields, in alphabetic order-ing:

� FaultTree� FaultTreeModelSubMechanisms� FaultTreeModels� MainMechanisms� Mechanisms� PreparatorySubMechanisms� SubMechanismModels� SubMechanismVariables� SubMechanisms� Variables� sqlite_sequence

Deltares 91 of 106


B.3 Fields in the hydraulic location configuration database (HLCD)

The hydraulic load configuration database, cf. section 4.5, contains the following fields, inalphabetic ordering:

� Calculation� Corrections� CorrectionsTable� CorrelationParameters� CorrelationTypes� DistributionParameters� DistributionParametersElement� DistributionParametersTable� DistributionTypes� DistributionTypes_2� DurationLineParameters� DurationLineTable� DurationLineTableElement� DurationLineTypes� General� ImplicInterpolationSupports� ImplicLocations� ImplicPerformanceLevelSupports� InputVariables� InterRegionalCorrelation� InterpolationSupports� LoadVariableTypes� LoadVariables� LoadVariablesData� Locations� PeakDurationElement� PeakDurations� RegionVariables� Regions� ResultVariables� Tracks� TypesOfHydraulicData� Uncertainties� UncertaintyDistributionParameters� UncertaintyTypes� WindDirections

B.4 Fields in the hydraulic region databases (HRD)

Each hydraulic region database, cf. section 4.6, contains the following fields, in alphabeticordering:

� AlphaClosingCriterions� BetaUClosingCriterions� ClosingCriterions� ClosingCriterionsPerDirection� ClosingScenarios� ClosingSituations� General� HRDInputVariables

92 of 106 Deltares

Database fields

� HRDLocations� HRDResultVariables� HRDWindDirections� HydroDynamicData� HydroDynamicInputData� HydroDynamicResultData� LocationTypes� UncertaintyModelFactor

Deltares 93 of 106


94 of 106 Deltares

C The collection of statistical data

The data that describe the statistics of all basic random variables of all the hydraulic regionsare available in Chbab and Eilander (2016) and Chbab and Groeneweg (2015). The statis-tics data are communicated, transferred and managed by means of a set of Microsoft Excelspreadsheets under version control (see Figure C.1).

Figure C.1: List of spreadsheets that contain elementary information on basic randomvariables associated with the water systems implemented in Hydra-Ring.

These data are stored in a generally accessible repository, under version management bymeans of the Tortoise Subversion software (freely available). In this way, changes in the dataare monitored. Each Microsoft Excel spreadsheet has a distinct label ’Final’, as soon as thedata is actually final.

An example of such a spreadsheet is shown in Figure C.2 for the random load variable ’dis-charge Lobith’. Notice the multiple tabfields, with all kinds of input data. The informationsources in the multiple tabfields together span the necessary and sufficient dataset for Hydra-Ring.

Also notice that in these spreadsheets the hydraulic uncertainties (both model uncertaintiesand statistical uncertainties) are stored. The hydraulic uncertainties are provided by Chbaband Eilander (2016) and Chbab and Groeneweg (2015). Once the statistical data are storedin the spreadsheets, the HLCD is built (see Figure C.3).

The HLCD database is the database with the general statistical data, independent of the dykelocation that is considered during a Hydra-Ring computation. The entire list of all spread-

Deltares 95 of 106


Figure C.2: Example of a Microsoft Excel spreadsheet that is used to prescribe the basisstatistical information on each random load variable used in Hydra-Ring. Thistable displays the duration line for the discharge at Lobith. Notice the multipletab fields, with other input data.

sheets containing the statistics is automatically linked with the TeamCity build server. Thisbuild server is an automatic means used along all the software projects at Deltares. Thisserver manages the automatic build of all software products and related artefacts.

The build server is used to automatically run the software tooling, described in reference [9], toconvert raw input data to a database. As shown in Figure C.3, the most recent HLCD.sqlitecan be taken from the server as artefact. The procedure to produce the database takes about15 minutes.

Figure C.3: Automatic build of the HLCD database on the server.

96 of 106 Deltares

The collection of statistical data

The processing of the hydraulic data, on the contrary, is not automatically done by means ofthe TeamCity server, since the amount of data transferred by these procedures is too large.The software to process the hydraulic data for the several water systems is ready and availablefor all current water systems (see Figure C.4).

Figure C.4: List of the complete set of databases used by Hydra-Ring. On top: the HLCD-database, the remainder of the list comprises hydraulic databases (HRD).

Deltares 97 of 106


98 of 106 Deltares

D Class diagrams

Throughout chapter 4, multiple aspects of the datamodel and the database are discussed. Inthis appendix, some of these aspects are visualized by means of class diagrams.

For the combination of results over several failure mechanisms, multiple classes are invented.These classes (main mechanism, mechanism, mechanism model, fault tree and submecha-nism) related to each other through the class diagram visualized in Figure D.1.

Figure D.1: Class diagram for the functionality to combine the results over several failuremechanisms.

Deltares 99 of 106


The project database has an extensive structure, containing many data regarding the specificflood defence. Along section 4.3, multiple aspects of this database are described. The keyelements of this database, as well as their mutual relations, are visualized in Figure D.2.

Figure D.2: Class diagram for the project database.

100 of 106 Deltares

Class diagrams

In the field Numerics, the numerical settings can be set. This field relates directly to multipleclasses, notably variable, submechamism and design table. Details on the relations to otherclasses are provided in Figure D.3.

Figure D.3: Class diagram for the numerical settings data fields.

Deltares 101 of 106


Multiple field within the project database related to wind-induced waves. The effect of windscan be manipulated in several ways, described in section 4.3. The associated class diagramis visualized in Figure D.4.

Figure D.4: Class diagram for wind-induced wave data.

102 of 106 Deltares

Class diagrams

In section 4.3.5, the database field VariableDatas has been described. In this field, multiplekey aspects of the project database come together, notably the section, numerical settings,the statistical data for the strength part and the submechanism. The associated class diagramis visualized in Figure D.5.

Figure D.5: Class diagram for the variable data fields.

Deltares 103 of 106

https://beeldbank.rws.nl, Rijkswaterstaat / Henri Cormont

WTI2017WTI2017

PO Box 1772600 MH DelftBoussinesqweg 12629 HV DelftThe Netherlands

Documents

So ware for the assessment of primary ood defences H -R · Title Hydra-Ring 16.3 Client Rijkswaterstaat Project 1230088.021 Reference 1230088-021-0SC-0071 Pages 106 Classification