01 Structure of a Delft-FEWS Configuration

Introduction

The main part of a Delft-FEWS configuration is defined in sets of XML files. 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.

Stand alone client with configuration on local filesystem

Typically, a new Delft-FEWS configuration is first setup in a Stand alone application, using a configuration setup on the local file system. In this case, the 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.

Operator client configuration in local datastore and central database

When distributing the application, the configuration files are instead shared via a local datastore or the central database. The local datastore or the central database, stores the same local filesystem configuration directory structure in dedicated SQL tables, each table containing different configuration directory. 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. In the central database active versions of configuration items have synchLevel 11 whereas inactive configuration files have synchLevel 0. The ConfigRevisionSets table defines the active configuration.

RootConfig files

A small set of XML files referred to as the root configuration files. 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. Some configuration files may differ between operator client and/or forecasting shell server. These  files have a filename with a meaningful prefix such as 'oc_windows_' or 'fss_linux_'.

Elements of the configuration

The two tables below provide an overview of the configuration elements of Delft-FEWS. Table 1 Overview of different configuration items contained either in the config directory or in the database:

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:

1. 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. For instance, 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 and a data merge module HBV_Rhine_ForecastMergeInputs.xml. This clearly indicates the association between modules and brings structure to the configuration.

2. when multiple almost identifcal configuration files would be required, it is recommended wherever possible to use template configuration files. These template configuration files contain $ tagged variables that can be filled in as as properties when referred to 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 XML 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. 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.

Configuration versioning file naming conventions  (now obsolete)

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:

Another version of configuration will have a different version number. The <default> item is omitted. Examples: