...
Overview of all the combinations which are available for a successful run
Local and server runs
The philosophy: Local runs are used by the operator to run, check and potentially optimize a forecast by means of modifiers. Once the operator is satisfied with the forecast, a server run is started and the results are shared.
This is implemented as follows:
- Local run results are only available in the local OC and are removed from the database when the application is closed.
- Server run results (and the modifiers of this run) are stored in the central database and are available from any OC.
- Local run results overrule server runs. Even when a server run is started after a local run. This means server run results won't be visible in displays.
The fact that local run results overrule server runs means that the server run results won't be visible in graphs or spatial display, even for the operator who started the server run. As this behavior is not always wanted, this can be changed with the topology chosen in the IFD. Below are two different approaches to this.
Local and server runs - parent and child nodes
Within the IFD local run results behave differently based on the topology structure that is chosen. We explain what changes with an example. Typically the server run is the parent node of the local runs, see screenshot below.
- North Slope is the parent node of KUPA2, SGRA2 and CRKLA2.
- North Slope has a workflow which consists of 3 sub workflows, which are each connected to the child nodes of North Slope.
- The child nodes of North Slope have local run results (blue box), which will be visible instead of the results of the workflow of the parent node.
- If next the North Slope workflow is run (i.e. a server run), the local run results in the child nodes of North Slope will be removed.
- Note: Only the results in direct child nodes of a parent node are removed. This does not impact local run results elsewhere in the IFD.
If in this example KUPA2 would also have a child node with a local run (i.e. a nested child node) then this local run would not be deleted.
Note: This logic is based on the configuration of the Topology (i.e. parent nodes and child nodes) and not the content of the workflows linked to these nodes (i.e. workflows and sub-workflows).
Local and server runs - all child nodes
If you want to be able to see local and server runs at the same time, you can configure both the local and server run nodes as child nodes (without a parent node). In the screenshot below, the nodes that start with Save... are server runs, the other nodes are local runs. If you run a server run, the local run results are not removed, since they are not generated in a child node of the server run (as in the example above).
Note: for this to work well, it is necessary for the timeseries produced by all nodes to have unique moduleInstanceId / ensembleId combinations. For example, if you process rainfall for both the local run (e.g. Select Kolan rainfall) and the server run (e.g. Save Kolan), the resulting time series should be different. If they get the same moduleInstanceId, you need to configure different ensembleIds for both (e.g. "ifd" for the local run and "official" for the server run). If you don't do this, the workflows will still run, but the processed rainfall from the first run will be overwritten by the processed rainfall from the second run (since there is nothing different to be able to differentiate the two).
This is true in general, if you produce timeseries anywhere in Delft-FEWS which result in the same timeseriesSet definition (i.e. moduleInstanceId and ensembleId), the latter run will overwrite the timeseries from a previous run, also if the modules are run as part of different workflows etc.
Task properties panel
The bottom section of the forecast panel can be used to select the task properties of a node.
The following properties can be changed or set:
- State selection,
- Time zero,
- Forecast length,
- User description for the workflow,
- What-if scenario.
The majority of these settings can be adjusted in the bottom section of the panel (left screenshot). More options are available in the panel which can be started by clicking on the "edit run options" button (right screenshot).
The initial state selection, time zero and forecast length which are set directly after selecting a node can be determined by the configuration. The page 24 Topology describes which configuration options are available.
Task properties panel
The bottom section of the forecast panel can be used to select the task properties of a node.
The following properties can be changed or set:
- State selection,
- Time zero,
- Forecast length,
- User description for the workflow,
- What-if scenario.
The majority of these settings can be adjusted in the bottom section of the panel (left screenshot). More options are available in the panel which can be started by clicking on the "edit run options" button (right screenshot).
The initial state selection, time zero and forecast length which are set directly after selecting a node can be determined by the configuration. The page 24 Topology describes which configuration options are available.
Local and server runs
The philosophy: Local runs are used by the operator to run, check and potentially optimize a forecast by means of modifiers. Once the operator is satisfied with the forecast, a server run is started and the results are shared.
This is implemented as follows:
- Local run results are only available in the local OC and are removed from the database when the application is closed.
- Server run results (and the modifiers of this run) are stored in the central database and are available from any OC.
- Local run results overrule server runs. Even when a server run is started after a local run. This means server run results won't be visible in displays.
The fact that local run results overrule server runs means that the server run results won't be visible in graphs or spatial display, even for the operator who started the server run. As this behavior is not always wanted, this can be changed with the topology chosen in the IFD. Below are two different approaches to this.
Local and server runs - parent and child nodes
Within the IFD local run results behave differently based on the topology structure that is chosen. We explain what changes with an example. Typically the server run is the parent node of the local runs, see screenshot below.
- North Slope is the parent node of KUPA2, SGRA2 and CRKLA2.
- North Slope has a workflow which consists of 3 sub workflows, which are each connected to the child nodes of North Slope.
- The child nodes of North Slope have local run results (blue box), which will be visible instead of the results of the workflow of the parent node.
- If next the North Slope workflow is run (i.e. a server run), the local run results in the child nodes of North Slope will be removed.
- Note: Only the results in direct child nodes of a parent node are removed. This does not impact local run results elsewhere in the IFD.
If in this example KUPA2 would also have a child node with a local run (i.e. a nested child node) then this local run would not be deleted.
Note: This logic is based on the configuration of the Topology (i.e. parent nodes and child nodes) and not the content of the workflows linked to these nodes (i.e. workflows and sub-workflows).
Local and server runs - all child nodes
If you want to be able to see local and server runs at the same time, you can configure both the local and server run nodes as child nodes (without a parent node). In the screenshot below, the nodes that start with Save... are server runs, the other nodes are local runs. If you run a server run, the local run results are not removed, since they are not generated in a child node of the server run (as in the example above).
Note: for this to work well, it is necessary for the timeseries produced by all nodes to have unique moduleInstanceId / ensembleId combinations. For example, if you process rainfall for both the local run (e.g. Select Kolan rainfall) and the server run (e.g. Save Kolan), the resulting time series should be different. If they get the same moduleInstanceId, you need to configure different ensembleIds for both (e.g. "ifd" for the local run and "official" for the server run). If you don't do this, the workflows will still run, but the processed rainfall from the first run will be overwritten by the processed rainfall from the second run (since there is nothing different to be able to differentiate the two).
This is true in general, if you produce timeseries anywhere in Delft-FEWS which result in the same timeseriesSet definition (i.e. moduleInstanceId and ensembleId), the latter run will overwrite the timeseries from a previous run, also if the modules are run as part of different workflows etc.
Modifiers panel
...