| scrollbar |
|---|
...
Scenario creation
scenario generatie
Manier realiseren om gemakkelijk op basis van bestaand materiaal een scenario generen. Hiervoor zijn verschillende aanpakken mogelijk, zoals:
1. Methodiek / tool om automatisch of met een kleine inspanning data (uit FEWS) van een opgetreden echt situatie op te slaan om als scenario te gebruiken. Het huidige project voorziet alleen in een methodiek voor het verzamelen van alle benodigde data voor een scenario. Er wordt momenteel niet gewerkt aan een zogenaamde automatische scenario generator.
2. Bewerken van bestaand scenario, bijvoorbeeld het debiet op de Maas met een factor verhogen of verlagen. Deze aanpassingen zouden ook moeten doorwerken in het weerbeeld en meetlocaties. Dit is een complexe taak, hiervoor wordt eerst een aanpak uitgewerkt en voorgelegd. Het huidige project voorziet alleen in een methodiek voor het bewerken van een bestaand scenario op basis van eerdere ervaringen binnen FEWS Rivieren. Aad D. is van mening dat een kloppende meteorologie van ondergeschikt belang is.
3. Generatie van een scenario bij bepaalde waterstandsverwachtingen of afvoerdebieten met bijbehorend weerbeeld. Dit is voor nu niet realiseerbaar.
Bewerken scenario
...
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.
- 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. - Manipulate availability of data, to simulate (temporarily) failing data and systems:
...
- Simulated failure of measurements by deleting certain signals: measurements not available for a part of or the entire period of interest
- 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).
- Forecasts that become available (too) late
...
In een interne brainstormsessie op 2012-06-01 kwam het idee naar voren om in een scenario ipv de meetwaardes (i.e. de waarheid) de uitkomst van 1 van de ensemble members te gebruiken. KNMI maakt 50 weersverwachtingen elk met een kleine perturbatie. Met elke afzonderlijke weersverwachting kan het waterstandsmodel (en golvenmodel) ook worden doorgerekend. Een tijdserie hieruit ter plaatse van de meetstations kan worden gebruikt als een alternatief meetsignaal. Voordeel hiervan is dat het scenario consistent blijft (i.e. weer en water). Door het meetsignaal zo aan te passen, weet de speler niet wat de "goede" uitkomst is en verklein je de kans dat men alle scenario's "uit het hoofd" kent.
Meerdere scenario's maken obv ensemble's?
>>>>>> Metingen vervangen door 1 van de ensemble runs (betekent dat je ook het water 50 keer moet door rekenen)
Model data die fews toont verandert niet!!
Archiveren events
...
- .
Method: With the delay option you can make a specific forecast become available later than usual.
- .
- 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.- 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).
- To keep a consistent scenario, the adjustments to precipitation have to be followed through in the river discharge and precipitation measurements.
- Filter the observations (low pass). Calculate the difference between the filtered observations and the model results. Add this difference to the original observations.
- 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.
- Now that all the input data has been modified, run all the necessary forecast runs.
| Anchor | ||||
|---|---|---|---|---|
|
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 dataset 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 relevant data is stored within the database MATROOS and the local datastore of FEWS North Sea. Both MATROOS and the local datastore keep all data for at least 10 days, which is enough history for a storm surge event as is the case for the SVSD. (Please note that this condition needs to be check for each individual FEWS configuration where this method will be applied.)
This will result in a prototype, that keeps growing in functionality. If the remaining budget and time permits it, the final prototype will be tested within the FC2015 Serious Gaming environment.
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.Make a copy of all data in FEWS
The archive functionality should be configured and implemented in the operational FEWS system. This includes:
Archive of the Forecasts, Thresholds, TimeSeries of selected modules and the FEWS Configuration into Zip files.
Data storage availability
The archive_run will be scheduled on a daily / weekly basis and thus performed automatically. The archive is saved on a pre-defined location. The archive can be stored for a period of for example 1 year (via a rolling barrel method).
Note: It is not correct to use the local data store to make a copy of the data in FEWS, since the content of the local data store is not complete, but only a snap-shot of the current state of FEWS for a fixed period of time (e.g. the last 10 days). The content changes every second via the rolling barrel method. Therefore, this can not be used to recreate an event.
Retrieve copy based on time markers
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. The , with the following functionality is required (partially to be developed):
- Define time window for which to restore data
- Import data (i.e. Zip files) into a local data store
- Filter log file from
...
- BulletinBoardPlus on event-messages to generate the time line
...
Create an event-message using Bulletin Board to mark
Beginning and end of the scenario
Interesting events
The messages created by all users are stored in the same overall log file.
The template of the event should be the following (requires discipline of the user)
yyyy-mm-dd hh:mm <description of event>
These even-messages are stored amongst other messages and have to be filtered out afterwards, based on
Events entered by certain users
Events starting with the date and time tag as described above.
2b: Automated generation of time markers via thresholds
Create an event message into the Bulletin Board to mark
Beginning (and end) of the scenario
Interesting events, ie.
Approve forecast
Occurrence of predefined (water) levels
Which data is analyzed by the operator
The template of the event should be similar to the manual messages.
The messages are filtered out similar to the manual messages.
Please note that in the operational system there will be multiple users, simultaneously logged on to the FEWS North Sea system. The implementation for the above should be able to deal with this in a logical way.
FEWS-5806 Archiving and extended filtering of log messages
Archiving log messages
Create ArchiveRun module with export task LogEntriesArchive and include it in an archiving workflow. Log messages are archived by (periodically) running this archiving workflow .
Use constraints to select log messages that should be archived. A log message will be archived when its event code is configured as logEventContstraint option and/or the log message text contains the specified messageText configured as logEventConstraint option.
Configuration example:
<exportArchiveRun>
<archivePeriod start="-2" end="0" unit="day"/>
<archiveType>LogEntriesArchive</archiveType>
<logEventConstraint eventCode="Manual."/>
<logEventConstraint eventCode="Validation.HardLimit"/>
<logEventConstraint eventCode="Validation.SoftLimit" messageText="at Lobith"/>
<logEventConstraint eventCode="Workflow.ActivityStarted" messageText="Workflow 'Rijntakken_Forecast'"/>
<logEventConstraint eventCode="Workflow.ActivityCompleted" messageText="Workflow 'Rijntakken_Forecast'"/>
/exportArchiveRun>
In this example the following messages will be archived:
- all manual messages,
- all Validation.HardLimit messages
- Validation.SoftLimit messages only for Lobith
- Workflow.ActivityStarted/Finished messages only for workflow Rijntakken_Forecast
Retrieving archived log messages from archive
Log messages can be retrieved using ArchivedDialog. The user selects and downloads the log messages archive in the same way as for example thresholds.
1. ArchiveDialog configuration
Configure in this dialog an archive type LogEntriesArchive.
An example:
<archiveTask name="Log Entries" workflowId="Import_Archive_LogEntries" iconName="icons/LookUpTable.gif" queryServiceUrl="$ARCHIVE_SERVER_URL$">
<archiveRun>
<importDirectory>$ARCHIVE_IMPORT_PATH$</importDirectory>
<importArchiveRun>
<archiveType>LogEntriesArchive</archiveType>
</importArchiveRun>
</archiveRun>
</archiveTask>
2. ArchiveRun configuration
Create ArchiveRun module with import task LogEntriesArchive and include this module in the workflow specified in ArchiveDialog.
An example:
<importArchiveRun>
<archiveType>LogEntriesArchive</archiveType>
</importArchiveRun>
Displaying/filtering (archived) log messages in SystemMonitor
By default, all non-manual messages are displayed in LogBrowser tab, and all manual messages are displayed in BulletinBoardPlus.
For Water Coach purposes we need to display both manual and selected non-manual messages in one tab. For this purpose a new tab has been added – BulletinBoardPlus In this new tab we also have some more choices to create manual messages quickly.
To show this tab, configure in SystemMonitorDisplay:
<bulletinBoardPlus>
<tabName>Interesting events</tabName>
</bulletinBoardPlus>
We can also add several optional 'messageTemplates' to create quickly messages with a specific mark. An example:
<bulletinBoardPlus>
<tabName>Interesting events</tabName>
<messageTemplate>Analysed by operator</messageTemplate>
<messageTemplate>Phone line went dead</messageTemplate>
<messageTemplate>Emergency advice requested</messageTemplate>
</bulletinBoardPlus>
Similarly we can add several optional 'users' to quickly create messages from a specific user. An example:
<bulletinBoardPlus>
<tabName>Interesting events</tabName>
<usertemplate>Name 1</usertemplate>
<usertemplate>Name 2</usertemplate>
</bulletinBoardPlus>
Button Add message
Using this button we add a manual message 'plus'.
Manual message 'plus' is actually a standard manual message. The information entered in the additional fields, is stored in the messages text (message body) in LogEntries table field 'logMessage'. Compared to standard manual message , the additional fields are Event Time (default value is Current System Time) and messageTemplate.
The message text (body) entered in the example above is stored as follows:
Simone De Kleermaeker@05-12-2011 13:47:00@Phone line went dead@
If we enter also some additional text, the messages body looks like:
Simone De Kleermaeker@05-12-2011 13:47:00@Phone line went dead@my comment
View period
is applicable to the Event Time, not to the log message creation time. For example, if we choose one month, the log messages with event time inside this period are displayed. Event time of the messages generated automatically is the same as message creation time so column "Event time" shows the same time as column "event creation time"
User
The drop down box 'User' is filled with the current user name, the user names that are found in the table FewsSessions and the userTemplates as defined in the configuration. It is also possible to enter any name in this editable drop down box.
The users, configured with user templates, can be entered while creating manual messages. Configure the user templates if you want to enter usernames that are different from the system user.
<bulletinBoardPlus>
<tabName>Interesting events</tabName>
<messageTemplate>Analysed by operator</messageTemplate>
<messageTemplate>Phone line went dead</messageTemplate>
<messageTemplate>Emergency advice requested</messageTemplate>
<userTemplate>Simone De Kleermaeker</userTemplate>
<userTemplate>gast gebruiker</userTemplate>
</bulletinBoardPlus>
Template
The drop down box 'Template' is filled with templates configured in SystemMonitorDisplay <bulletinBoardPlus> tab. It is also possible to enter any text in this editable drop down box.
Other fields in the tab BulletinBoardPlus
Buttons Refresh, Save and fields log Level, Search in Message, Max number of events have the same meaning and behaviour as in standard BulletinBoard.
Zie ook notulen
Water Coach werksessie 2012-06-01
Aanwezig:
Frank Keppel
Rens van den Bergh
Michelline Hounjet
Simone De Kleermaeker
Martin Verlaan
Scenario bibliotheek
Verzameling opbouwen, waarin alle ooit gemaakte scenario's (= datastores) met per scenario alle bijbehorende scripts worden gearchiveerd. In dit assortiment van scenario's moeten ook scenario's zitten die over de overlappende gebieden van de verschillende FEWS systemen gaan (Kampen, Dordrecht)
Aanvulling:
Tijdens het gesprek van 2012-05-21 is nogmaals bevestigd dat het niet de bedoeling is om binnen dit project extra scenario's te maken. Scenario's worden gemaakt op het moment dat ze nodig zijn en verzameld op een centrale plek, i.e. de scenario bibliotheek. Aad Dollee acht het wenselijk om op termijn 10 of meer scenario's per groep (LCW, LCO, SVSD, HWG, WDIJ) ter beschikking te hebben. De applicatiebeheerder (Peter Weiland) zal dit moeten inrichten.
Planning (product 2): Afgerond. Het begin van de scenario bibliotheek is opgeleverd met de scenario's zoals gebruikt bij de WMCN oefening. De inrichting hiervan bij RWS ligt in handen van Peter Weiland. De al bestaande handleiding van de Water Coach (wiki) kan hierbij ter ondersteuning dienen.
Ter ondersteuning kan de Waterdienst/DID het mogelijk maken om in de operationele omgeving naast het scenario ook zaken ten behoeve van het script vast te leggen. Denk bijvoorbeeld aan:
...
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.