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