Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
scrollbar

<work in progress>

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 developpeddeveloped. hiero
3. Recreate the data for an event, by running all relevant workFlows in a stand alone copy of the FEWS system.

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. 

Bewerken scenario

...

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 chance 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 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

      ...

        1. become available (too) late

      ...

        1. .
          Method: With the delay option you can make a specific forecast become available later than usual.
      1. 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.

      Anchor
      bulletinboardplus
      bulletinboardplus

      Archiveren events

      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!!

      ...

      hiero


      This functionality is built in gradually into FEWS. Every step will be discussed with the client (or a representative) after implementation. During these discussion, ideas to fine-tune the next implementation step will arise and can still be incorporated.

      ...