{scrollbar} |
The Bayesian Network adaptor (BNA) sets up a Bayesian network based decision support system (DSS) for coastal hazards and impacts in hotspot areas, according to the framework developed in task 3.3 of the RISC-Kit project (www.risckit.eu).
The BNA is an executable that uses
to create
The BNA can be used both in FEWS and outside FEWS.
The BNA has been developed in c++.
Currently the BNA for windows consists of an executable and a number of dll's. Moreover, it depends on
(to be expanded by Mirko)
Linux users have to compile the source code (courtesy to Mirko who provided the source code and configuration file).
The BNA works with relative paths to read and write data. Initially, users have to create (manually) a directory Risckit/Modules/Genie/<case_study_name>/ which contains:
In principle input/ contains the latest simulation results of the hydro/morphodynamic model which transforms offshore boundary conditions to onshore hazards (e.g. XBeach; in the remainder the term "hazard transformation model" is used.) and trainingData/ contains all previously run simulations, which should eventually amount to the "100 simulations" of task 5.3.
If the user works with the FEWS system the folders input and trainingData remain empty, as they are filled by the general adaptor (GA). The corresponding actions that the GA needs to be programmed to take are described in the next section. If the user works outside the FEWS system, the folder input is obsolete and trainingData needs to be filled manually, which is described in the section thereafter.
The CSO runs the "100" simulations within FEWS and the Bayesian network is the last model of the model train that is operated by the GA (the site specific config file) following the hazard transformation model. To use the BNA in order to create the Bayesian network based DSS, the user has to add three actions to his/her site specific GA. In general the model output of the hazard transformation model is imported to FEWS after each run. First, the output is transformed to two separate files which are saved in input/: hazardbc.nc (or hazardbc_<measure>_<bin>.nc if a structural measure is in place) contains the boundary conditions and hazard.nc contains 'gridded' output of the onshore hazards. These netCDF files must follow strict format rules in order to comply with the requirements of the BNA (see section netCDF files). Second, a batch file copies the two files to a new directory with an arbitrary but unique name in trainingData/. Third, the GA calls the BNA, which creates output/BN<hotspotname>.dsl.
Example configurations can be found at the bottom of this page (General Adaptor Run Example Configuration).
Working outside FEWS is conceptually the same as working inside FEWS. The difference is that the tasks of the GA have to be executable manually. The user will run the "100 simulations" of task 5.3. with the hazard transformation model only and collect all model outputs. A matlab script similar to this one insert link to matlab script here (from Haris) can be used to transform those outputs to hazardbc.nc and hazard.nc files of the right format and to save them in separate directories in trainingData/. The the BNA.exe can be run and will create output/BN<hotspotname>.dsl.
This section describes the formats of files that need to be placed in model and workDir by the user before the BNA is run and that are written to input and trainingData by the GA and its batch file. Note that the user develops his/her own GA and has to ensure that it writes files of the correct format to input and trainingData. It also describes the files that are written by the BNA to output.
The JSON files are the backbone of the Bayesian network. The BNA reads JSON files from workDir/ (and in the future: writes output to output/) and they constitute the link between the simulation data and the BNA. They
The required JSON files have to be created manually by the user. They are info.json, BCnodes.json, Rnodes.json, Hnodes.json, Cnodes.json, Mnodes.json and vulnerabilities.json. Their format is explained below and examples are provided.
JSON files can be created with any text editor. They are built on two structures: (1) a collection of name/value pairs and (2) an ordered list of values. Details can be found at http://json.org/.
The file info.json contains six or seven fields, depending on the grid being unstructured or structured.
The structure files contain the variable definitions (including the links between them) for the Bayesian network. Variables of the same category are defined in the same file. Because there are five categories, i.e. boundary condition (BC), receptor (R), hazard (H), impact (C) and measure (M), there are five structure files. Each variable is defined by a name/value pair. The name is a dummy name, consisting of the category and an index, e.g. BC1 (boundary condition 1) or H1_R1 (hazard 1 for receptor 1). The paired values are JSON objects themselves with at least five name/value pairs on their own:
Some categories have additional (optional) keywords. This is illustrated in the following examples, which yield this BN structure: BNdemo.dsl
Similar to the other JSON files each vulnerability is defined by a name/value pair, where the name is <receptorID_impactID> and the value is a JSON object with two keys:
An example corresponding to the demoBN is given here vulnerabilities.json and detailed explanations on creating the mapping are given in the Tutorial: Creating a vulnerability mapping.
The netCDF files contain data from the hazard transformation model. They do not contain time series data, but a single summary statistic of the time series, e.g. maximum, mean, minimum, or mode. The hazard boundary conditions (e.g. maximum wave height, predominant wave angle, etc for a single location at the 20m water line) are stored in a file with name "hazardbc.nc", while the onshore hazards (e.g. gridded data of maximum flood depths, maximum flow velocities, maximum erosion) are stored in a file with name "hazard.nc". The format of the two files is a bit different, however for both applies that
The text files provide information on the receptors' spatial distribution across the case study site. For each <receptor> variable defined in Rnodes.json there must be a corresponding <receptor>.txt file which relates all individual receptors to their sub-areas and grid points of of the hydraulic model (e.g. XBeach). The files should be tab-separated and contain, in this order (!), the columns areaID, receptorID and gridpointID. Moreover, the data must be sorted such that the receptorIDs are ascending.
Example from the demoBN are ResBuildings.txt and People.txt. (To create People.txt it has been assumed that there are two people in each building and that they can be found at this location at any time.) Note that there are duplicates of receptorID, because individual receptors may be effected by multiple surrounding grid points. For a step by step explanation of creating this file, see the page Tutorial: Creating a <receptor>.txt file. The approach can be slightly modified to obtain a txt file for a "latent receptor", i.e. a buffer zone around a receptor, which is computationally treated as a receptor, but not explicitly represented as such in the BN. See Tutorial: Creating a <receptor>.txt for a latent receptor
(to be expanded in April)
The shape files are not required for the BNA, but are relevant for the webviewer. They are the shapefiles that have been used to create the <receptor>.txt files and should eventually be stored in the directory shapefiles/.
(to be expanded by UAlg & IMDC)