You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 73 Next »

info.json

Summary

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 BN adaptor is an executable that uses

  1. .nc files of storm simulations
  2. .txt files indicating receptor locations 
  3. .json files specifying the structure of the BN
  4. a .json file specifying the vulnerability relationships for the hotspot area

to create

  1. a .dsl file that can be opened with the Bayesian network software GeNIe (www.dslpitt.org)

System Requirements

The BNA has been developed in c++. 

Windows

Currently the BNA for windows consists of an executable and a number of dll's. Moreover, it depends on

Linux (tba)

Linux users have to compile the source code. 

Configuration

Directory Structure

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:

  • input/
  • model/
    • BNA.exe & related .dll's
  • output/
  • trainingData/
  • workDir/
    • info.json
    • BCnodes.json
    • Rnodes.json
    • Hnodes.json
    • Cnodes.json
    • Mnodes.json
    • <ID_of_receptor>.txt
    • vulnerabilies.json
    • shapefiles/
      • areas.shp & related GIS files

The folders input, output and trainingData remain empty. They are accessed by the BNA and the general adaptor (GA).

Overview on Data Process

 

Input and Output Files

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.

netCDF files

 

(to be added soon)

JSON files

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/. 

JSON files are read from workDir/ and written to output/ by the BNA. The following sections describe the files in workDir, which have to be manually created and placed there by the user. Example files are provided as well. 

Info file

info.json contains four fields:

  • "name" specifies the filename of the resulting BN
  • "grid_type" is either "structured" or "unstructured"
  • "hazardbc_time" and "hazard_time" should be 1 and denote the time dimension of the netCDFs 
  • "hazardbc_stations" should be 1 and denotes the location of the boundary condition
  • "hazard_stations" specifies the number of model grid points
Structure files

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. The data format is JSON (http://www.json.org/). A JSON object is an unordered set of name/value pairs. 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 with at least five name/value pairs on their own:

    • "ID" contains the actual variable name. Consistent naming of the variables across all files (netCDF, JSON, text) is crucial:
      • For BC variables the ID must correspond to the FEWS ID of a variable in the hazardbc.nc file.
      • For R variables the ID points to the name of a text file.
      • For H variables the name has two parts which are divided by a single underscore. The first part indicates the type of local hazard and must correspond to the FEWS ID of a variable in the hazard.nc's. The second part indicates for which receptor type the hazard is calculated and hence it must correspond to a receptor ID. 
      • For I variables the name again has two parts divided by a single underscore indicating the type of impact and the receptor affected. Both parts reappear in the vulnerabilites.json.
      • For M variables there are no special requirements as yet.
    • "title" is what is displayed in Genie. It may contain spaces. 
      • Not allowed characters: ( ), €, £ 
      • Allowed characters: [ ], % 
    • "bins" is an array containing the bin values itself or the interval boundaries for each bin, depending on the value in "nobins". The values can either be numeric or a string starting with a letter without any spaces.
    • "nobins" is an integer defining the number of bins (or states) in the BN. If "nobins" equals the length of the "bins" array, each value in "bins" is a bin. If "nobins" is one smaller that the length of the "bins" array, the values in "bins" are taken to be the interval boundaries of each bin.
    • "parents" is an array of the "ID"s of parent variables or "None".
    • (optional:) "aggregation" describes the method by which data will be extracted from netCDF files. This is only relevant for hazard variables. It can have either "max" or "mean" as a value, indicating whether the average or maximum value of surrounding hydraulic grid points should be computed.

This is illustrated in the following examples, which yield this (INSERT LINK HERE) BN structure. 

Vulnerability file

(to be added soon)

Text files

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 containing three columns of data (in this order): areaID, receptorID and gridpointID. Important: The data must be sorted such that receptorID is increasing! An example is given here: ResBuildings.txt. Note that there are duplicates of buildingID, because individual buildings may be effected by multiple surrounding grid points. For a step by step explanation of creating this file, see the page Creating a <receptor>.txt file.

Shape files

(to be added soon)

General Adaptor Run Example Configuration

(to be added soon)

 

  • No labels

Disclaimer