Introduction
The configuration of Delft-FEWS is defined in a set of XML files and a properties file. In this section the different parts of the configuration are introduced. An understanding of these different parts of the configuration is required before attempting configuration of a Delft-FEWS system.
Normally, when developing a Delft-FEWS configuration, this is first setup in a Stand alone application, which typically has a configuration setup on the local file system. When distributing the application, the configuration files are instead shared via a local database or the central database.
- the Stand alone application configuration is defined by a fixed set of directories, each containing different parts of the configuration. These directories are all contained under the Config directory.
- in a local datastore or central database, the structure of config file directories is stored in dedicated SQL tables, each table containing different parts of the configuration. Each of the tables in the local database reflects one of the sub-directories in the file system.
When initiating the Stand alone Delft-FEWS application, it will look for configuration stored in the local datastore or in the filesystem. If both are found, then the system will ask the user to choose which to use. If neither is found then an appropriate error message is issued and the system will stop. The configuration in the central database belongs to a dedicated Delft-FEWS implementation of a particular forecasting system. In the live system situation the contents of the database will be shared between all operator clients and forecasting shell servers in the system, and is therefore expected to be identical in all parts of the system. A small set of XML files referred to as the root configuration files may differ between operator client and/or forecasting shell server. This root configuration is required to identify for example if the particular instance of Delft-FEWS is operating in stand-alone mode or as an operator client, or on windows or linux. These root configuration files have no effect on the hydrological configuration and are normally not changed during configuration of the forecasting system side of Delft-FEWS.
Elements of the configuration
The two tables below provide an overview of the configuration elements of Delft-FEWS. Table1 identifies for which type of configuration a single files per type is allowed and for which multiple instances for each type of configuration may exist.
Table 1 Overview of different configuration items contained either in the config directory or in the database.
Configuration Item | Directory on File System | Table name in file system | Single/ |
Definition of regional configuration, including all locations, parameters etc. | RegionConfigFiles | RegionConfigurations | Single |
Definition of system configuration items, including the plug-ins available to the system, definition, icons etc. | SystemConfigFiles | SystemConfigurations | Single |
Definition of modules for handling data and running forecasting models | ModuleConfigFiles | ModuleInstanceConfigs | Multiple |
Definition of workflows for running sequences of modules | WorkflowFiles | WorkflowFiles | Multiple |
Cold states for modules. Zip file containing model specific data exported by GA usually before running a model | ColdStateFiles | ColdStateFiles | Multiple |
Definition of mapping of ID's and parameters between external sources (e.g. telemetry, modules) and ID's and parameters defined in the DELFT-FEWS configuration | IdMapFiles | IdMaps | Multiple |
Definition of unit conversions between external sources (e.g. telemetry, modules) and units used in DELFT-FEWS | UnitConversionFiles | UnitConversions | Multiple |
Definition of flag conversions between external sources (e.g. telemetry, modules) and flags used in DELFT-FEWS | FlagConversionFiles | FlagConversions | Multiple |
Definition of layout of user displays, including What-if scenarios, Grid Display etc.) | DisplayConfigFiles | DisplayConfigurations | Multiple |
Definition of module parameters stored in DELFT-FEWS | ModuleParameters | ModuleParameters | Multiple |
Zipped files containing datasets for modules used by the forecasting system. | ModuleDataSetFiles | ModuleInstanceDatasets | Multiple |
Definition of HTML template files used in creating HTML reports for use on the web server. | ReportTemplateFiles | ReportTemplates | Multiple |
Map layers (shape files) used in main map display and spatial interpolation | MapLayerFiles | MapLayerFiles | Single |
Images used in reports etc | ReportImageFiles | ReportImageFiles | Single |
Icons used in main map display and button bar | IconFiles | IconFiles | Single |
| Several XML files describing some of the settings specific to the Operator Client used (e.g. client configuration, IP addresses) | RootConfigFiles | RootConfigFiles | Multiple |
Versions of configuration and XML file naming conventions
For each of the configurations managed by Delft-FEWS in either the database or on the file system as described above, various versions of configuration may exist. Configurations that are active and used as a default can be identified both in the file system and in the database. On the file system an optional naming convention is introduced to identify which of the possible multiple versions are used as a default. The naming convention for the default version:
<Name of XML configuration file>SPACE<Version number>SPACE<default>.xml
Another version of configuration will have a different version number. The <default> item is omitted.
Examples:
| example | description |
|---|---|
| Explorer 1.00 default.xml | A "default" version of the configuration settings for the FEWS Explorer |
| Explorer 2.00.xml | A second version that is not made active, since it has not the "default" tag. |
The current practice does not advocate the use of the "default" tag naming convention any more.
In the central database the default version for each configuration item is identified in an associated table with synchLevel 11.
Naming conventions for defining module config files
For complex forecasting systems the number of configuration files can be very large. This is particularly the case for the module config files, and because the names of these are used in TimeSeriesSets for storing and retrieving data, the names given should be chosen logically. Before configuring large numbers of XML files it is wise to:
- define a naming convention and use this throughout. An example of such a convention is where a number of steps are used to process data prior to running a model.
A forecast model run for the HBV model in the Rhine may be defined in a module called:
HBV_Rhine_Forecast.xml
Data processing steps such as an interpolation module may then be called
HBV_Rhine_ForecastInterpolate.xml
Or a data merge module
HBV_Rhine_ForecastMergeInputs.xml
This clearly indicates the association between modules and brings structure to the configuration.
- with multiple more or less identifcal configuration files, use template configuration files. Template configuration files contain $ tagged variables that can be filled in as as properties when referred to in by other XML files.
XML Schemas and schema validation
Each configuration item contained in an XML file must be formatted as specified in an appropriate XML schema (XSD file). Validating against the schemas is an important step in configuring Delft-FEWS, as the primary validation makes sure the syntax of the configuration made is correct. There are two types of configuration in Delft-FEWS. In the first set, for each different schema type, only one default configuration file may be used and the name of the configuration file is unique. For the second set of configuration, multiple configuration types may be available for a specific schema. The names of these may be defined by the user. An XML file contained in the regional configuration element is then used to register these XML files with a user specified name to the system, and identify the type of configuration. This file is referred to as a descriptor file.
