Scenario creation



A scenario for the water coach can be created in several ways.

1. Make a copy of the localDataStore directly after an interesting event. If the events spans a longer period of time, in which case relevant data might be removed by the rolling barrel, several copies should be made while the event is still in progress.

2. If the data from FEWS is archived in some way, retrieve the data for an interesting historic event from the archive. This could be done using the archiving functionality from FEWS. To facilitate this, the bulletinBoardPlus has been developed.

3. Recreate the data for an event, by running all relevant workFlows in a stand alone copy of the FEWS system.



Scenario tuning



Once a scenario has been created, the scenario can be tuned to better fit the training (and learning objectives). We suggest a few possible approaches.



    
	
  1. One reason to want to modify the scenario, is to 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 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. 
	
  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. 
		
    2. Forecasts that become available (too) late.
      
Method: With the delay option you can make a specific forecast become available later than usual.
      3. 
	
    
	
    3. 
	
  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. 
		
    2. To keep a consistent scenario, the adjustments to precipitation have to be followed through in the river discharge and precipitation measurements.
      3. 
		
    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. 
		
    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. 
		
    5. Now that all the input data has been modified, run all the necessary forecast runs.
      6. 
	
    
	
    4. 








Marking interesting scenarios using bulletinBoardPlus in FEWS



Making a copy of the relevant data may not under any circumstances disturb the workflow of the operators. Therefore, the actual copying of the data set will only be performed after the crisis has passed. To facilitate the retrieval of archived data, we have extended the bulletinBoard functionalities to bulletinBoardPlus.



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, 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 displays both types of messages and provides more options to create manual messages quickly. 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.



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.



Within the period that the archive is saved, the data for a specific time window can be retrieved from the archive based on time markers (start and stop time) and imported to a local data store. For this, the archive server will be used, with the following functionality:





Scenario library



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.