Note: This is documentation for version 4.11 of Source. For a different version of Source go to the Space Directory.
Page tree
Skip to end of metadata
Go to start of metadata

The Environmental Flow Node (EFN) is designed to simulate environmental flow requirements according to a set of actions. Environmental flow requirements may generally be classified as either in-stream or floodplain requirements , where the former creates flow conditions that remain within the river channel, and the latter creates flow conditions that spill over bank. 


The EFN provides a means of capturing prescriptive descriptions of water patterns that the environment requires. These definitions of watering patterns are captured as ‘actions’ within the EFN and many combinations of actions can be prescribed. The two types of actions presented in the EFN have been designed to capture the most commonly defined environmental flow requirements specified in environmental flow studies and water regulations. These actions allow you to construct a collective environmental water requirement by using combinations of environmental demand rules. These are:

  • Spell based - A spell can be defined as a period of time that the flow has a set of desired characteristics. This type of action can by used to specify a flood or fresh event, usually associated with a recruitment event such as to trigger fish movement, water floodplain vegetation, a flow pattern or a minimum flow, usually applied to maintain minimum habitat requirements; and
  • Translucency - specifies the flow requirements in terms of some other time series, usually the release from a dam based on the inflow of the dam.

A combination of these actions can be used to meet specific environmental outcomes. They are configured in the environmental flow node's feature editor..

For each action in the EFN, you can configure several characteristics that can be altered. A common feature across action types is the concept that they can be applied to a specific time of the year. This is termed the ‘season’ of the rule and is defined by a start and end day and month value. 

Using the node in Source

Double-click the node to open its feature editor, shown in Figure 1.

Specify maximum account deduction can specify a limit to water debited to an accounting system; if this deduction cap is more than total volume ordered, the total order is debited. This parameter can be specified as a value or a function. By default the volume a node orders (on top of the downstream order)is accounted for. Here, the user can specify a function to limit that volume to a maximum, for example: Max(0, Full Requirement – Minimum Constraint), so that water already in transit is not included in the account deduction.

Right clicking on the top action menu item allows you to add either a Spell Based or Translucency Action. Multiple actions and action types can be added to a single node. The actions will work together to determine a total requirement per timestep. 

Right clicking on the action title allows you to rename, delete or enable/disable the action. 

Figure 1. Environmental Flow Node

Spell Based

A rule may be configured to order water to follow a distinct pattern of separate flow events. Spell based rules define the characteristics of the flow events, the pattern of their occurance, and conditions under which a rule will become active and order may be made. Flow rules can be made active or inactive dynamically during a modelling run. 

Figure 2. Spell Based Action menu

Menu ItemDescription
 Season Period in which action is required (this is to specify a season within a year, the year specified has no relevance).
 Number of spells in season An action could include a number of independent spells. If you are including multiple spells, be sure to check the number of spells required for success (see success criteria).
 Minimum interval between planned spells:This is to specify the required period between spells and is only relevant in case the action consists of more than 1 spell. This does not guarantee that a spell will be independent from the next, only that recording of the next spell will begin after a period of time since the last spell ended. To ensure spell interdependence the spell end thresholds should be used. This is only relevant in case the action consists of more than 1 spell.

  Desired frequency:

Determines the desired return (or recurrence) interval. In case the Environmental Flow Node (EFN) is managed by the Environmental Flow Manager (EFM), the desired frequency is used in the calculation of Antecedent Condition, which is used by the manager to prioritise events. If the EFN is not managed by the EFM, the node will use the desired frequency to determine if the action should be targeted. 
 Initial condition

This is to initialise the number of successful spells (for start of run) and is only relevant when the flow node is operating independently from an Environmental Flow Manager. The ‘initial condition’ is based on how Desired Frequency has been defined. The user specifies the number of successful spells in the period (as used for the Desired Frequency) before the start of the run. The ‘initial condition’ impacts ordering only, not antecedent conditions.

 Allow orders: This is enabled by default. If this box is not ticked, the flow node will only record (natural/unregulated) success of the actions. It will not place any orders. These non-ordering actions are not visible to the Environmental Flow Manager.
 Allow forcing of spells: If this box is ticked, the flow node will attempt to force an action without the spell start threshold being met. Forcing will occur at the end of a season when there is only the number of required days left. For example, if a 10 day spell is required, forcing will occur in the last 10 days of the season, if the required event has not already occurred within the specified season. 
Number of season failures before forcingIf Allow forcing of spells has been selected, the user needs to specify after how many unsuccessful seasons the node should begin forcing the action.
End spell if it will fail

A spell will start when Spell Start Threshold is met and will continue for the specified Minimum spell duration. When End spell if it will fail is enabled, a spell may end before the Minimum spell duration is reached, if it is expected to fail. This decision whether a spell will fail is based on the target and the duration as specified in the Spell Definition and Success Criteria.

If End spell if it will fail is not enabled, tracking of spells can be restricted to being within the spell timeframe. This may result in a successful spell occurring with the node that ordered the spell not being considered to have a successful spell, as it does not align with the spell timeframe.

The End spell if it will fail option is selected by default. The user must disable the option in case of a minimum flow requirement through the season, which should continue even if has not been successfully met in the season so far. 

Time since last successful spell This is to initialise Time since last successful spell recorder. It does not impact the value for antecedent conditions.
Time since last successful spell in a successful season This is to initialise Time since last successful season recorder. It also defines the initial value for antecedent conditions. 
Override Condition

If enabled, the user can choose to override the default method of evaluating Antecedent Condition. This would allow to user to include more advanced ecological response model. See Antecedent Condition in scientific reference guide for more details.

*The message “Note: This node  is managed by the Environmental Flow Manager. It will decide if targets result in orders. ‘Desired frequency’ will still be used to determine the Condition.” will appear in the User Interface if the Action is linked to an Environmental Flow Manager.

Spell Definition

Figure 3. Spell Definition menu

Menu ItemDescription
Spell Start Threshold:Required expected flow for action to be triggered. The expected flow at the environmental flow node is the maximum of the Minimum Constraint at the upstream node and the Order at the downstream node. The user can implement a fixed flow rate, a data source or a function to determine Spell Start Threshold. Functions should be evaluated before the Order Phase.
Target: Target flow rate that the Action is to achieve. The user can implement a fixed flow rate, a data source, a function or a flow target table to determine a spell’s Target
Limit target to reference flowLimit target to reference flow: If enabled, the Target flow rate will be constrained to the Reference flow rate When turned on, this allows the user to specify a time series, to which the flow requirement (target) will be limited. For example, the without development (natural) flow can be used to limit the flow requirement.
Reference flow:

Reference flow can be determined by a single value, a data source, a function or a flow target table. The target flow (full requirement) will be the minimum of either the Target or Reference flow

Minimum spell duration:Required duration of each spell to be successful. This is the minimum length of time a target flow needs to be maintained to be considered a succesful spell, regardless of whether water has been ordered to augment it or not.
Extend spell duration

This allows the spell to extend more than the minimum duration when possible. The user can either always allow or disallow the spell to extend beyond the minimum duration using a binary TRUE or FALSE, or use a function to evaluate whether the spell can be extended. The function should evaluate to TRUE or FALSE.

A spell is considered a success as soon as it has met the minimum criteria. The spell, however, is not considered complete while it is still running under extension, and the time since last successful spell will increment accordingly. If a spell extends to the final day of a season, the rate of fall will not occur/be considered. 
End thresholdA flow threshold below which the flow should fall to consider the spell finished. This can lead to a spell being longer than the minimum required duration. A spell will end either when the end threshold is reached or the season has ended.

The flow should fall below the end threshold for a spell to be considered finished. End threshold is used in scenarios with multiple spells to enable the flow rate to be dropped for a specified time period after one spell before beginning another spell. The model will not actively try to achieve the end threshold flowrate and the end threshold is not taken into account when measuring success. If the flow does not drop below the end threshold, the spell will end when the season has ended.

Duration required below thresholdThis is used in combination with the End Threshold and is only relevant in case of actions with multiple spells. To get spell independence, the flow may need to be below a certain threshold for a minimum period of time.

Success Criteria

The user can specify a number of success criteria. All criteria need to be met for an action to be considered successful. This allows for flexibility around what a success may look like. For example, if it important to achieve the full event volume, but the flow level may vary around the flow target, the target % could be set to a low value, and the volume to 100%.

Figure 4. Spell Based Action Success Criteria Menu


Proportion of required flow target that needs to be achieved to call an event a success.
Duration Proportion of the defined Minimum spell duration that needs to be achieved to consider a spell successful.

VolumeProportion of total action volume that needs to be achieved to call an event a success.
Number of spells required for success  The number of spells required to achieve a successful season. This can only be an equal or smaller number than the Number of Spells in SeasonRelevant in case of actions with multiple spells, if the action could be called successful if a number but not all spells have been achieved.

Rise and Fall

Figure 5. Spell Based Action Rise and Fall Menu


Days, Rate (ML/d) or Percentage to define a spell’s rise and fall. For more details see scientific reference guide

  • Days: Number of days over which the Rise and Fall should occur
  • Rate: Daily change in flow rate during Rise and Fall
  • Percentage: Increase or decrease flow by x percentage for user specified number of days.
Rise: Period, rate or percentage at which flow will rise from expected flow (Minimum Constraint) to the flow Target.

Period or rate at which the flow will fall from the Target flow rate to the Fall Target. The rate of fall is only relevant when expected flow (minimum constraint) and downstream order are both less than targeted flows. The fall period will lie within the defined season. There will only be a fall period if a spell is successful, this will be reflected in the Full Requirement.

Fall Target:

Targeted flow rate to reduce (fall) flow to. This is used to determine the falling limb of the event based on number of days or rate at which flow should fall. However, if the Percentage method is selected, fall target will be ignored.

Note: The rise and fall criteria are not considered in determining spell success. 

Translucency Action

This action allows you to define reference relationships where flow would be allowed to pass through a storage or restrictions be placed on extraction in an unregulated system.

Figure 6. Translucency Action Menu


Period in which action is required (this is to specify a season within a year, the year specified has no relevance).
Translucency reference flow: Flow to be used to determine the targeted flow (and hence the release from storage) – this could be a time series of inflows to the storage. It could also be a function, which allows flexibility in the definition of the flow requirement.
Translucency percentage: The percentage of the reference flow that is required.
Start Threshold: Flow rate threshold to be reached before the action is triggered.
End Threshold:Translucency action will be ended if flow rate falls below this threshold.

Note: For function used in Environmental flow node, if the function is using modelled variables about a action, any time of evaluation prior to and including environmental flow prioritisation can be used. If the function is using modelled variable about a group (group enabled or group cost), then environmental flow prioritisation must be used and additionally, the modelled variable date range must be set to current iteration.