Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

  1. One reason to want to modify the scenario, is to chance change the outcome, i.e. the observations. The forecaster might recognize the scenario and remember the actual values that occurred. Rather than modifying the entire scenario (and all model results), you can simple change the observations. By doing this, you change to objective of the training from reaching (remembering) the correct forecast to reaching a forecast in a correct way.
    Method: Use the ensemble runs for the meteo forecast to run the hdyro hydro model several times (with small perturbations to the meteo driving force). Instead of using the actual observations, replace them with the results of 1 of the ensemble runs at the location of the observations. With this approach you keep the meteo and hydro data set consistent. Furthermore, this one time effort results in as many alternatives as there are ensemble runs.
  2. Manipulate availability of data, to simulate (temporarily) failing data and systems:
    1. Simulated failure of measurements by deleting certain signals: measurements not available for a part of or the entire period of interest
      Method: Use a database editor (e.g. DBvisualize) to remove certain observations from the data set (or do not import them in the first place).
    2. Forecasts that become available (too) late.
      Method: With the delay option you can make a specific forecast become available later than usual.
  3. Modification of the data while keeping a consistent data set can become very complex. However, depending on the system, this might be an option. It is not possible to give a generic methodology for this, since every FEWS system is different. Instead we will describe the main steps you could take for FEWS system used to forecast water levels in a river, where rainfall is the driving force.
    Method: In this example FEWS system, we start by importing the meteo forecast for participation. This forecast is the driving force of the water movement model, forecasting river discharge and water levels.
    1. Multiply the precipitation forecast data with a constant factor, using a workflow where the input and output have the same ModuleInstanceId. Check the result of your modifications on the discharge and water level forecasts. Repeat these steps until the required results have been reached (iterative process).
    2. To keep a consistent scenario, the adjustments to precipitation have to be followed through in the river discharge and precipitation measurements.
    3. Filter the observations (low pass). Calculate the difference between the filtered observations and the model results. Add this difference to the original observations.
    4. If you use an ARMA module, rerun the models, because the adaptation of the observations will influence the results of the models. Make sure the result is still satisfactory.
    5. Now that all the input data has been modified, run all the necessary forecast runs.

...

The bulletinBoardPlus is designed to create manual and automatic messages to mark with minimum effort the beginning and end of the scenario and the occurrence of interesting events.

...

 Message templates can be set-up for frequently occurring manual messages.

...

Furthermore Furthermore, messages can be created automatically marking the beginning (and end) of the scenario and interesting events, e.g. :

...

approval of a forecast and exceeding of predefined (

...

warning) levels

...

BulletinBoardPlus . BulletinBoardPlus displays both types of messages and provides more options to create manual messages quickly.
Log  Log messages can be archived by (periodically) running an archiving workflow and retrieved using ArchivedDialog.

These messages can also be used to set up a script. In addition, one could organize a structural approach to archive all documentation that could be used to create a script associated with this scenario. These documentation could consist of:

...

Archive module

The archive module of FEWS already allows the archiving of (a selection of) all data in FEWS. With the additionally archived messages marking interesting events, the period of data to retrieve can be defined easily.

...

The set up of the ScenarioScriptDatabase is such that it can be used to store any scenario (and associated scripts) you ever create. This database should be stored in a central place, where it can not be modified. When trainees want to train, they can either use a local copy of (part of) this database, or the application config could directly refer to this database on a shared disc. The latter options ensures the availability of an up to date scenario library at all times.