...
An example of a node which is configured with a warm state search period is given below.
A configuration example is given below.
...
It is also possible to set the default state selection for a node or a group of nodes to a cold state selection. This is used, for example, in FEWS system which are used for calibration purposes.
An configuration example is given below.
...
| Code Block |
|---|
<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 <initialStartTimeCardinalTimeStep> and initialEndTimeCardinalTimeStep<initialEndTimeCardinalTimeStep>.
To force user edits to the start and/or end time to a certain time step the options cardinalTimeStepStartTime <cardinalTimeStepStartTime> and cardinalTimeStepEndTime <cardinalTimeStepEndTime> can be used.
If the option initialStartTimeCardinalTimeStep <initialStartTimeCardinalTimeStep> is used then the start time will not change when the system changes. The same applies for the end time and the option initialEndTimeCardinalTimeStep<initialEndTimeCardinalTimeStep>.
A configuration example is shown below.
...
| Code Block |
|---|
<node id="ProcessTest" name="Process Data">
<workflowId>ProcessImports</workflowId>
<relativeStartTime unit="day" value="-10"/>
<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 <coldStateFromCurrentRun> can be used.
Below a configuration example
| Code Block |
|---|
<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.
...
If time zero changes the cold state selection should also change to keep the relative period the same.
Forecast length
To set the forecast length at a fixed length the option forecastLength <forecastLength> can be used.
It is possible to force the end time of the forecast (time zero plus forecast length) to match a certain time step by using the option initialForecastLengthCardinalTimeStep<initialForecastLengthCardinalTimeStep>.
The end time of a node is only forced to the match this time step at the moment the user selects the node for the first time.
To force the end time of a node to match a certain time step in the cases the forecaster tries the edit the default forecast length the option cardinalTimeStepForecastLength <cardinalTimeStepForecastLength> can be used.
By default the end time of a node changes when the system time changes so that the forecast length stays the same.
However if for a node the option initialForecastLengthCardinalTimeStep option <initialForecastLengthCardinalTimeStep> is configured then the end time of the node stays the same if the time zero changes.
Below a configuration example of a node for which a forecast length, an initialForecastLengthCardinalTimeStep an <initialForecastLengthCardinalTimeStep> and a cardinalTimeStepForecastLength a <cardinalTimeStepForecastLength> is configured.
| Code Block |
|---|
<node id="B10_Main_RTC" name="Run model"> <workflowId>Big10_RTCTools_RT</workflowId> <forecastLength unit="hour" multiplier="24"/> <cardinalTimeStepForecastLength unit="hour"/> <initialForecastLengthCardinalTimeStep id="HE6"/> <displayGroupId>Main_RT-RTC</displayGroupId> <timeSeriesButtonsPanelId>RT_buttons_Main</timeSeriesButtonsPanelId> <viewPermission>execute</viewPermission> <visibleModifierGroup>RT</visibleModifierGroup> <graceTime unit="hour" multiplier="1"/> <localRun>true</localRun> <saveLocalRunEnabled>true</saveLocalRunEnabled> <showRunApprovedForecastButton>true</showRunApprovedForecastButton> </node> |
...
The end time of the run (forecast length) was first set to time zero plus 24 hours. Because this time wasn't a valid time for the configured
initialForecastLengthCardinalTimeStep <initialForecastLengthCardinalTimeStep> the end time was set to first valid time prior to the end time.
...
| Code Block |
|---|
<node id="ZWF_LHM_Z0_REF2017BP18" name="Files LHM zonder zout"> <workflowId>ZWF_LHM_Z0_REF2017BP18</workflowId> <timeZero date="2004-01-01" time="00:00:00"/> <localRun>false</localRun> </node> |
...
To make the time zero editable and/or to shfit the time zero compared to the system time the option timeZeroShift <timeZeroShift> can be used.
| Code Block |
|---|
<nodes id="WaterOrder HADT1" name="Water Order Apalachia"> <timeZeroShift unit="hour" multiplier="0"/> <node id="WaterOrder_HADT1" name="Adjust Water Order"> <locationId>HADT1</locationId> <workflowId>CalculateSpill_WaterOrder_HADT1</workflowId> |
...
If the shift is set to 0 then the time zero will be editable but equal to the system time.
Topology groups
It is possible to split the configuration of the topology in separate configuration files.
...