...
Overview of all the combinations which are available for a successful run
Local and server runs
Local run results overrule server runs. Even when a server run is started after a local run. This means that the server run results won't be visible in graphs or spatial display.
When a forecaster has finished the process of running local runs and possibly creating modifiers the optimize the results of the forecast then a server run is started.
The IFD will then also automatically upload the modifiers which are related to the server run. By doing this the forecaster will make the results of his local runs available for all other forecasters in the FEWS system.
But because local runs always overrule server runs the result of the server run will not be visible in the OC of the forecaster who started the server run until the OC is restarted (a restart will remove the local runs).
This problem is solved in the following way in the IFD. The server run is usually the parent node of the local runs.
In the example above North Slope is the parent node of KUPA2, SGRA2 and CRKLA2. The parent node North Slope has a workflow which consists of 3 sub workflows. These 3 sub workflows are each connected to the child nodes of North Slope,
Because the child nodes of North Slope all have a local run the results of these workflows are visible instead of the results of the workflow of the parent node. However when the workflow of the North Slope is run again then the results of local runs will
automatically be removed when the server run of North Slope finished. When a server run finishes then the local runs of the child nodes will automatically be removed when the IFD notices that a server run for North Slope is finished. Note that this logic is based on the configuration
of the topology and not on the fact the workflow of North Slope consists of sub workflows of its child nodes. In addition only the local runs of child nodes which are directly below North Slope will be removed.
...
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 that the server run results won't be visible in graphs or spatial display, even for the operator who started the local run.
As this behavior is not always wanted, this can be changed with the topology chosen in the IFD.
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 notes) and not the content of the workflows linked to these nodes (i.e. workflows and sub-workflows).
Task properties panel
...