Page History

...

<?xml version="1.0" encoding="UTF-8"?>
<topology xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews https://fewsdocs.deltares.nl/schemas/version1.0/topology.xsd">
	<nodes id="C" name="C">
		<workflowId>workflowC</workflowId>
		<node id="A" name="A">
			<workflowId>workflowA</workflowId>
		</node>
		<node id="B" name="B"/>
	</nodes>
</topology>

IFD runs

localRun

Workflows By default all the workflows started from a leaf node are by default started in IFD mode (i.e. local run). The results of an IFD-run are only temporary available in FEWS (until the next restart) and are only available and visible at the operator client which started the run. IFD runs are typically used to evaluate the effect of modifiers on the results of a forecast.

Server run

A workflow which is Workflows started from a group node will (nodes) are by default be started as a server run. A server run will run at a FSS when it is started from an operator client. When it is started from a stand alone it will run locally but the results of the run will be available after a restart of the system.

It is possible to You can change these default settings by using with the element localRun<localRun>.In  In the example below the runs from leaf nodes A (localRun=false) and B (defaults to false) will run in server mode and the runs started from the group node C will run in IFD mode (localRun=true).

<?xml version="1.0" encoding="UTF-8"?>
<topology xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews https://fewsdocs.deltares.nl/schemas/version1.0/topology.xsd">
	<nodes id="C" name="C">
		<workflowId>workflowC</workflowId>
		<localRun>true</localRun>
		<node id="A" name="A">
			<workflowId>workflowA</workflowId>
			<localRun>false</localRun>
		</node>
		<node id="B" name="B"/>
	</nodes>nfonodes>
</topology>

previousNodeId

It is possible to connect nodes in the topology. In the example below the node STKA2 is connected to two previous nodes (SBFQ2 and ISKQ2). The way nodes are connected plays an important role when running workflows in IFD mode. 

<node id="STKA2" name="STKA2 Stikine R Wrangell">
		<previousNodeId>SBFQ2</previousNodeId>
		<previousNodeId>ISKQ2</previousNodeId>
		<workflowId>STKA2_Forecast</workflowId>
</node>

...

Example previousNodeId

The example below shows the situation before the forecaster starts an IFD run for the node STKA2. The topology tree shows that this node has not run yet (icon is a black dot)  and that it is connected to two previous nodes SBFQ2 and ISKQ2.

Image ModifiedImage Added

When the forecaster starts an IFD run for node STKA2 (see arrow) Delft-FEWS will detect that node STKA2 is connected to two other nodes which have to run before the run for STKA2 can be started.One  One of these nodes (SBFQ2) also has a previous node which has to run prior to running this node. Before running node STKA2 the IFD system will make sure that first all the necessary previous nodes are run in the correct order before node STKA2 will be run.
The example below shows the screenshot on the right shows the forecast tree after the run for STKA2 was finished. It shows that not only an IFD run was started for STKA2 but also for all its previous nodes.Image Removed

enableAutoRun

By default the workflow on a leaf node is started automatically after selecting the node. This can be disabled by setting the option <enableAutoRun> to false.The  The option will apply to all nodes.

enableRunUpstreamServerNodes

For IFD (local) runs the connected previous nodes are always started before the IFD run for the selected node can be run. 

For server runs the connected previous nodes are by default not taken into account. If the option <enableRunUpstreamServerNodes> is set to true the previous nodes will also be started prior to running the workflow of the selected node.

checkStatusPreviousServerRun

The option <checkStatusPreviousServerRun> can be used to force that a server run can only be started if the status of all of its previous nodes is fully successful. 

enableCrossGroupNodeReferencing

Previous nodes which are connected to a node but belong to a different group in the topology tree are ignored by default when starting previous nodes for a selected node. By setting the option <enableCrossGroupNodeReferencing> to true previous nodes in a different group will also be taken into account.

Please noteNote,  if if the same workflow node is selected more than once, and a description is specified, then a notification dialog pops up after the OK button is clicked. If the user chooses to change the description, then the edit run options dialog comes back, and the description text would be selected (which indicates the description text is ready to be edited).

Secondary workflow

It is possible to define a secondary workflow for a node. This secondary workflow can be run by clicking the button  in the button bar.

...

runSecondaryWorkflowWithTaskRunPropertiesFromIFD 

The secondary workflow runs by default with the settings in the xml-file. Since the 2019.02 release however it is also possible to run the secondary workflow with the settings from the IFD.

...

It is possible to manually select the task properties which will be used in the runs started from the IFD. This can be done in the panel below the forecast tree. The picture belows below shows an example of this panel.

...

It is possible to disable the possiblity possibility to edit the forecast length by using the option <useForecastLengthFromInteractiveForecastDisplay>.

...

When the system time changes the selected state will also change so the relative time compared to time zero will stay the same.

Warm state selection period

The option warm state selection period can be used to set the state selection to a period (relative to the system time) in which the system will search for a warm state.

...

	<nodes id="WAPN6HUD_calb" name="WAPN6HUD">
				<workflowId>WAPN6HUD_Stats_Calibration</workflowId>
				<coldState unit="day" multiplier="18628"/>
				<node id="WAPN6HUD_Waterbalance_Multi-year" name="Waterbal_MY">

Fix cold state selection 

With the fixedColdState option, the cold state can be fixed to a selected dateTime by the user in the GUI by selecting the checkbox "Keep cold state at current selection". This fixed coldState is inherited by the downstream nodes. 

Note: When a user selects the option to fix a cold state to a certain date/time then this will only impact the local client. Only when the user starts a server run for this node the changes (modifiers) will be send to the server and impact the other users.

Image Removed   Image Removed

To enable this option, you need to configure a few files (config examples are give below):

• Topology.xml
  • <fixedColdState>, which defines the location attribute modifier in FEWS to store the selected cold state:
    • locationId: location the modifiers will be made.
    • modifierTypeId: refers to modifier type id as defined in ModifierTypes.xml
    • fixedColdStateLocationAttributeId: attribute in which the selected cold state dateTime is stored. This is a date/time attribute.
    • fixedcoldStateGroupLocationAttributeId: attribute in which the cold state group is stored. This is a text attribute.
  • <workflowId>, which should refer to a workflow including the lcoationId mentioned above
• ModifierTypes.xml
  • <locationAttributeModifier> to define the modifierTypeId as referenced in the Topology
  • <modifiersGroup> (optional) if you make use of modifiersGroup make sure to list the locationAttributeModifier id here as well
• LocationSets.xml
  • <attribute> to add both cold state attributes to the relevant locations
  • <dateTimePattern> to define the format of the dateTime attribute
• basins.csv
  • add column to create (empty) attributes as defined in locationSets.xml

Note: the location for which the fixedColdState is configured needs to be part of the workflow which is connected to that topology node.  

			<node id="coldRelativeStateStartTimeNode">
				<workflowId>workflow2</workflowId>
				<coldState unit="hour" multiplier="6"/>
 				<fixedColdState>
					<locationId>basinA</locationId>
					<modifierTypeId>coldStateModifier</modifierTypeId>
					<fixedColdStateLocationAttributeId>coldStateDateTime</fixedColdStateLocationAttributeId>
					<fixedColdStateGroupLocationAttributeId>coldStateGroup</fixedColdStateGroupLocationAttributeId>
				</fixedColdState>
			</node>

	<attributeModifiers>
		<locationAttributeModifier id="coldStateModifier" name="fixed cold state">
			<modifiableGroup name="coldStateModifiableGroup">
				<locationSetId>basins</locationSetId>
				<attribute id="coldStateDateTime"></attribute>
  				<attribute id="coldStateGroup"></attribute>
		    </modifiableGroup>
		</locationAttributeModifier>
	</attributeModifiers>

<locationSet id="basins">
		<csvFile>
			<file>basins.csv</file>
			<geoDatum>WGS 1984</geoDatum>
			<id>%BASIN%</id>
			<name>%SHORT_NAME%</name>
			<dateTimePattern>yyyy-mm-dd HH:mm</dateTimePattern>
			<x>0</x>
			<y>0</y>
			<z>0</z>
			<attribute id="coldStateDatetime">
				<dateTime>%coldStateDatetime%</dateTime>
			</attribute>
			<attribute id="coldStateGroup">
				<text>%coldStateGroup%</text>
			</attribute>
		</csvFile>
	</locationSet>

BASIN, SHORT_NAME, coldStateDatetime, coldStateGroup
basinA, basinA, ,
basinB, basinB, ,

coldStateStartTime

Alternatively, a fixed coldStateStartTime (available since 2019.02) can be configured. This dateTime is hardcoded in the xml, and can not be changed by the user.

	<nodes id="WAPN6HUD_calb" name="WAPN6HUD">
				<workflowId>WAPN6HUD_Stats_Calibration</workflowId>
				<coldStateStartTime date="2019-01-01" />
				<node id="WAPN6HUD_Waterbalance_Multi-year" name="Waterbal_MY">

No initial state

The option <noInitialState> can be used to disable the state selection for a node so that the state will be selected by the workflow.

An example of a node which has this option enabled is shown below.

Image Removed

A configuration example is given below.

<nodes id="Southeast" name="Southeast">
	<workflowId>Southeast_Forecast</workflowId>
	<noInitialState></noInitialState>

Relative period panel

When the forecaster wants to run a workflow for a certain period of time then the relative period panel is a good option to use. The picture belows shows an example of the relative period panel.

Image Removed

This option is used, for example, in the HERMES-system. Below a configuration example:

<node id="ProcessTest" name="Process Data">
	<workflowId>ProcessImports</workflowId>
	<relativePeriod unit="day" start="-30" end="0"/>
	<localRun>false</localRun>
</node>

When the system time is changed then the start time and end time will also change so that the relative period will stay the same for a topology node.

It is possible to force the initial start time and end time to match a certain time step. This can be done by using the options <initialStartTimeCardinalTimeStep> and <initialEndTimeCardinalTimeStep>.

To force user edits to the start and/or end time to a certain time step the options <cardinalTimeStepStartTime> and <cardinalTimeStepEndTime> can be used.

If the option <initialStartTimeCardinalTimeStep> is used then the start time will not change when the system time changes. The same applies for the end time and the option <initialEndTimeCardinalTimeStep>.

A configuration example is shown below.

<node id="Process" name="Process Data">
	<previousNodeId>Import</previousNodeId>
	<workflowId>ProcessImports</workflowId>
	<relativePeriod unit="day" start="-10" end="-5"/>
	<cardinalTimeStepStartTime unit="hour" multiplier="6"/>
	<initialStartTimeCardinalTimeStep unit="hour"/>
	<cardinalTimeStepEndTime unit="hour" multiplier="6"/>
	<initialEndTimeCardinalTimeStep unit="hour"/>
	<localRun>false</localRun>
</node>

Relative period panel with only a start time

It is possible to a create a relative period panel in which the end time is hidden.

Below an example of such a panel.

Image Removed

Cold state from current run

To set the state selection at a node to the cold state selection which was used in another run the option <coldStateFromCurrentRun> can be used.

Below a configuration example 

<node id="rainfallpolicy_tweed" name="Set Rainfall Policy">
	<workflowId>Tweed_Rainfall_Forecast</workflowId>
	<coldStateFromCurrentRun>
		<workflowId>Tweed_URBS_IFD_Forecast</workflowId>
		<coldState unit="day" multiplier="2"/>
	</coldStateFromCurrentRun>
	<defaultModifierId>Rainfall Policy</defaultModifierId>
	<visibleModifierGroup>URBS_Official_Rainfall</visibleModifierGroup>
	<localRun>true</localRun>
	<showRunApprovedForecastButton>false</showRunApprovedForecastButton>
</node>

In the example above the cold state which was used in the current run from workflow "Tweed URBS IFD forecast" will be used.

It is possible to define a default state selection for the cases that a current run is not available yet. In the example above this default is set to a cold state selection of 2 days before time zero.

If time zero changes the cold state selection should also change to keep the relative period the same.

Fix cold state selection 

With the fixedColdState option, the cold state can be fixed to a selected dateTime by the user in the GUI by selecting the checkbox "Keep cold state at current selection". This fixed coldState is inherited by the downstream nodes. 

Note: When a user selects the option to fix a cold state to a certain date/time then this will only impact the local client. Only when the user starts a server run for this node the changes (modifiers) will be send to the server and impact the other users.

Image Added   Image Added

To enable this option, you need to configure a few files (config examples are give below):

• Topology.xml
  • <fixedColdState>, which defines the location attribute modifier in FEWS to store the selected cold state:
    • locationId: location the modifiers will be made.
    • modifierTypeId: refers to modifier type id as defined in ModifierTypes.xml
    • fixedColdStateLocationAttributeId: attribute in which the selected cold state dateTime is stored. This is a date/time attribute.
    • fixedcoldStateGroupLocationAttributeId: attribute in which the cold state group is stored. This is a text attribute.
  • <workflowId>, which should refer to a workflow including the lcoationId mentioned above
• ModifierTypes.xml
  • <locationAttributeModifier> to define the modifierTypeId as referenced in the Topology
  • <modifiersGroup> (optional) if you make use of modifiersGroup make sure to list the locationAttributeModifier id here as well
• LocationSets.xml
  • <attribute> to add both cold state attributes to the relevant locations
  • <dateTimePattern> to define the format of the dateTime attribute
• basins.csv
  • add column to create (empty) attributes as defined in locationSets.xml

Note: the location for which the fixedColdState is configured needs to be part of the workflow which is connected to that topology node.  

			<node id="coldRelativeStateStartTimeNode">
				<workflowId>workflow2</workflowId>
				<coldState unit="hour" multiplier="6"/>
 				<fixedColdState>
					<locationId>basinA</locationId>
					<modifierTypeId>coldStateModifier</modifierTypeId>
					<fixedColdStateLocationAttributeId>coldStateDateTime</fixedColdStateLocationAttributeId>
					<fixedColdStateGroupLocationAttributeId>coldStateGroup</fixedColdStateGroupLocationAttributeId>
				</fixedColdState>
			</node>

	<attributeModifiers>
		<locationAttributeModifier id="coldStateModifier" name="fixed cold state">
			<modifiableGroup name="coldStateModifiableGroup">
				<locationSetId>basins</locationSetId>
				<attribute id="coldStateDateTime"></attribute>
  				<attribute id="coldStateGroup"></attribute>
		    </modifiableGroup>
		</locationAttributeModifier>
	</attributeModifiers>

<locationSet id="basins">
		<csvFile>
			<file>basins.csv</file>
			<geoDatum>WGS 1984</geoDatum>
			<id>%BASIN%</id>
			<name>%SHORT_NAME%</name>
			<dateTimePattern>yyyy-mm-dd HH:mm</dateTimePattern>
			<x>0</x>
			<y>0</y>
			<z>0</z>
			<attribute id="coldStateDatetime">
				<dateTime>%coldStateDatetime%</dateTime>
			</attribute>
			<attribute id="coldStateGroup">
				<text>%coldStateGroup%</text>
			</attribute>
		</csvFile>
	</locationSet>

BASIN, SHORT_NAME, coldStateDatetime, coldStateGroup
basinA, basinA, ,
basinB, basinB, ,

coldStateStartTime

Alternatively, a fixed coldStateStartTime (available since 2019.02) can be configured. This dateTime is hardcoded in the xml, and can not be changed by the user.

	<nodes id="WAPN6HUD_calb" name="WAPN6HUD">
				<workflowId>WAPN6HUD_Stats_Calibration</workflowId>
				<coldStateStartTime date="2019-01-01" />
				<node id="WAPN6HUD_Waterbalance_Multi-year" name="Waterbal_MY">

No initial state

The option <noInitialState> can be used to disable the state selection for a node so that the state will be selected by the workflow.

An example of a node which has this option enabled is shown below.

Image Added

A configuration example is given below.

<nodes id="Southeast" name="Southeast">
	<workflowId>Southeast_Forecast</workflowId>
	<noInitialState></noInitialState>

Relative period panel

When the forecaster wants to run a workflow for a certain period of time then the relative period panel is a good option to use. The picture below shows an example of the relative period panel.

Image Added

This option is used, for example, in the HERMES-system. Below a configuration example:This panel can be configured in the following way.

<node id="ProcessTest" name="Process Data">
            	<workflowId>ProcessImports</workflowId>
            <relativeStartTime 	<relativePeriod unit="day" valuestart="-1030" end="0"/>
            	<localRun>false</localRun>
 </node>

Cold state from current run

To set the state selection at a node to the cold state selection which was used in another run the option <coldStateFromCurrentRun> can be used.

</node>

When the system time is changed then the start time and end time will also change so that the relative period will stay the same for a topology node.

It is possible to force the initial start time and end time to match a certain time step. This can be done by using the options <initialStartTimeCardinalTimeStep> and <initialEndTimeCardinalTimeStep>.

To force user edits to the start and/or end time to a certain time step the options <cardinalTimeStepStartTime> and <cardinalTimeStepEndTime> can be used.

If the option <initialStartTimeCardinalTimeStep> is used then the start time will not change when the system time changes. The same applies for the end time and the option <initialEndTimeCardinalTimeStep>.

A configuration example is shown below.Below a configuration example 

<node id="rainfallpolicy_tweedProcess" name="SetProcess Rainfall PolicyData">
	<workflowId>Tweed_Rainfall_Forecast</workflowId><previousNodeId>Import</previousNodeId>
	<coldStateFromCurrentRun>
		<workflowId>Tweed_URBS_IFD_Forecast</workflowId>
		<coldState<workflowId>ProcessImports</workflowId>
	<relativePeriod unit="day" start="-10" end="-5"/>
	<cardinalTimeStepStartTime unit="dayhour" multiplier="6"/>
	<initialStartTimeCardinalTimeStep unit="2hour"/>
	</coldStateFromCurrentRun>
	<defaultModifierId>Rainfall Policy</defaultModifierId>
	<visibleModifierGroup>URBS_Official_Rainfall</visibleModifierGroup>
	<localRun>true</localRun>
	<showRunApprovedForecastButton>false</showRunApprovedForecastButton>
</node>

...

<cardinalTimeStepEndTime unit="hour" multiplier="6"/>
	<initialEndTimeCardinalTimeStep unit="hour"/>
	<localRun>false</localRun>
</node>

Relative period panel with only a start time

It is possible to define a default state selection for the cases that a current run is not available yet. In the example above this default is set to a cold state selection of 2 days before time zero.If time zero changes the cold state selection should also change to keep the relative period the same.a create a relative period panel in which the end time is hidden.

Below an example of such a panel.

Image Added

This panel can be configured in the following way.

<node id="ProcessTest" name="Process Data">
            <workflowId>ProcessImports</workflowId>
            <relativeStartTime unit="day" value="-10"/>
            <localRun>false</localRun>
 </node>

Forecast length

To set the forecast length at a fixed length the option <forecastLength> can be used.

...

Below a screenshot of the same node after the sytem system time was changed. The time zero is changed but the end time of the node is still fixed at the same time.

...

To make the time zero editable and/or to shfit shift the time zero compared to the system time the option <timeZeroShift> can be used.

...

It a date/time attribute is not modified the default value will be shown. It is also possible to configure an overruling value if the date/time attribute is unmodfiedunmodified.

This can be done by using the overrulingUnmodifiedDateTimeAttributeValue. The value can be configured by defining an offset and a time step.

...

The option <url> can be used to configure an URL for each node. After selecting the node the URL will be displayed automatically in the web browser display.

timeSeriesButtonPanelId

(Since 2014.01) Reference to time series button panel that becomes visible when this topology node is activated. For this functionality you need to configure the time series button panel in Explorer.xml and add 17 TimeSeriesButtonsPanels to the DisplayConfigFiles.

Config examples

Examples from Topology.xml c.q.  TopologyGroup.xml are shown below.

...

	<nodes id="SSD_NL" name="SSD NL">
		<node id="Overview_WMCN" name="Overview Nederland">
			<mainPanel>schematic status display</mainPanel>
			<scadaDisplayId>ScadaOverview_WMCN</scadaDisplayId>
			<scadaPanelId>Overview_WMCN</scadaPanelId>
		</node>
		<node id="Forecast_WMCN" name="Forecast Nederland">
			<mainPanel>schematic status display</mainPanel>
			<scadaDisplayId>ScadaOverview_WMCN</scadaDisplayId>
			<scadaPanelId>Forecast_WMCN</scadaPanelId>
		</node>
	</nodes>

To be added by Onno...timeSeriesButtonPanelId

...

Other ways of interacting with displays through the Topology configuration

mapExtentId

To automatically select a zoom extent in the map after selecting a node, the element <mapExtentId> can be used.

...

A green or blue icon indicate that the workflow was successful, . The icons also indicate if the time zero which was used in the last run of a node is the same as the time zero which is currently selected for a node.

...

In addition it is not common that modifiers are made at group nodes. In the cases that it is required that modifiers can be shown (and edited) at a group node the default behavour behaviour can be

changed. This option is only available at group nodes.

...

The overview panel uses the half of the space of the modifiers panel. By hiding this panel, a lot of space is available for the detail panel. This is a useful feature when users only create modifiers at a node and want to use all the available space for the detail panel.

...