An action configured to maintain a minimum flow, where flow should be maintained above a certain limit for particular periods of the year. It is similar to the flood/fresh rule, but with
- Timing (preferred time of the year) (1)
- Total Duration (what proportion of the specific period needs to be at or above the threshold) (2)+(3)...
- What is the minimum consecutive period to be considered (e.g. do single days above the threshold count toward the seasonal total or is it only continuous periods of 7 days or more)
- Flow threshold defined in terms of
- A magnitude (minimum flow threshold to achieve environmental benefit),
- A time series or pattern to accommodate a variable threshold level
In addition to the definitions of flow requirements which effectively create a ‘pulse’ of environmental demand, the user can create a temporally varying rule by simply defining the pattern of the flow required as well as a trigger condition. The trigger condition will be either a set start day or a flow threshold (7) which has to be reached.
Introduction
The Environmental Demand Model (EDM) provides a way of simulating environmental water (flows) requirements in Source, effectively by generating 'environmental demands' in a manner analogous to other water user demands in Source.
Environmental water (flows) requirements are represented in the EDM as ‘flow rules’. A flow rule will predict the water required to achieve predefined environmental flow objectives/requirements. These requirements may be directed at in-channel and/or floodplain habitats and ecosystems.
| icon | false |
|---|
In Source, Environmental Demand (ED) is modelled using the environmental demand node. Refer to Environmental Demand for further details. The node can be configured to fulfill either in-stream or floodplain requirements.
It is important to note the two different ways in which an ED node can be set up. These are:
EDM on main river channel link - Typically used to specify flows relating to the provision of in-stream requirements, such as providing: suitable water depths (eg. for fish passage); wetted habitat (eg. for fish breeding); connectivity (eg. connecting drought refuges); or to meet in-stream water quality targets (eg. for dilution flows). The ED node will allow almost all such requirements to be configured in Source.In addition, an in-stream requirement ED node can also be set up to order water that ultimately moves from the river channel to the floodplain via an anabranch, distributary or flood-runner (for example, at 90% bank-full). For Australian users, this is the way in which environmental water requirements for floodplain ecosystems are often specified ie. according to flow requirements for the main river channel, that are based on known hydrologic linkages with the floodplain (eg. X ML/d for Y days duration to ensure inundation of floodplain wetland Z); and
EDM on floodplain branch link: Better represents the actual environmental demand of a floodplain ecological asset. Different to the above example, in which an in-stream flow requirement (eg. X ML/d for Y days duration to ensure inundation of floodplain wetland Z) is effectively a surrogate for the actual floodplain environmental demand.
An environmental demand node configured on a floodplain branch (below a splitter) orders water according to the hydrologic characteristics of that branch - by specifying a flow rate at a point in the branch - with the splitter specifying the hydrologic relationship with the main channel (via a ratings table or curve).Note: Although it is essential to understand the two distinctions, it is possible to fulfill many in-stream and floodplain requirements in the same model by changing the configuration of the node.
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. How these situations are configured in Source is largely dependent on the conceptualisation used to model the interaction between the channel and the floodplain.
Actions
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. The environmental flow node can only currently create high flow events i.e. flows over a specified threshold. This type of action can by used to specify a flood fresh, 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.
You can select whether the EDM is inclusive or exclusive of downstream orders. If inclusive (default value), then the order generated by the EDM will be the difference between the EDM’s water order and the downstream order. In this case, the Inclusive of Downstream Orders slider is selected to YES. This assumes that the EDM can take advantage of the required water downstream to meet all or part of its requirements. If the EDM is exclusive of the downstream order, the EDM’s water will be added to the downstream order - the slider is selected to NO.
The Specify maximum account deduction parameter allows you to specify maximum account deduction which will limit water debited to an accounting system; if this deduction cap is more than total order water, the total order water 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), i.e. the residual requirement, is accounted for. Here, the user can specify a function to limit that volume to a maximum, for example: Min(0, Residual Requirement – Minimum Constraint), so that water already in transit is not included in the account deduction. This could also allow for re-crediting of return flows, if the maximum volume would be allowed to go negative.
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
Demand nodeFlow Node
Spell Based
Flow rules can be made active or inactive dynamically during a modelling run. In order to control rules throughout the model run, each rule can have a defined condition threshold. This condition threshold is compared to the ‘condition’ time series for each time-step and the flow rule is turned on or off for that time-step as required. This functionality is specifically designed to allow the construction of asset based rule sets that vary according to water availability.
Figure 2.
ED node, ReferenceSpell Based Action menu
Condition
Environmental rules can be toggled on and off using a pre-defined condition tracker. If the condition tracker falls bellow a specified threshold, the rule is turned on; if above a threshold, the rule is turned off.
| Info | ||
|---|---|---|
| ||
| Note: Only one condition tracker can be defined for a collection of rules. |
A condition tracker can be used in a variety of environmental applications, such as:
- To represent the "health" of an environmental asset; or
- To represent environmental rules that turn on or off for a specified account balance.
Condition trackers can be defined as a constant value, a time-series or as a function. In the example shown in Figure 3, the function specifies storage capacity in the scenario.
Figure 3. ED node, Condition tracker
If you have an account configured (in the Resource Assessment Explorer), you will be able to enable or disable Account Distribution using the contextual menu.
Figure 3. EDM, Account distribution
Flow rules
The four types of flow rules presented in the EDM have been designed to capture the most commonly defined environmental flow requirements specified in environmental flow studies and water regulations. These four types of environmental demand rules allow users to construct a collective environmental water requirement by using combinations of environmental demand rules. The four rule types are:
- Minimum flow - specifies a minimum flow, usually applied to maintain minimum habitat or dilution flow requirements;
- Flood/Fresh - specifies a flood fresh, usually associated with a recruitment event such as to trigger fish movement, water floodplain vegetation;
- 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; and
- Flow pattern - specifies a pattern of flow, used to define multi-peak events.
Common elements to configure are:
- Season - the period of the year over which the rule should be considered (eg a winter flooding rule only);
- Reporting interval - what is the acceptable number of years between applying the flow rule (eg high flows are only required once in 5 years);
- Augmentation Options - the preference for achieving the watering requirement. There are three augmentation options:
- Natural flow or matching a reference time series - usually uses a modelled scenario without development, and water demand for each rule will match the successful meeting of the rule that would occur under the reference flow;
- Extend - if a flow rule has started to be met, then water is ordered to extend the watering (eg tributary inflows have commenced a flood, and releases from the main channel dam may be used to extend the duration of the event); and
- Force - if by the end of the reporting interval, the flow rule has not been met, then a release will be ordered. This is similar to waiting until the last possible moment to meet the water requirements in the anticipation that the water requirements will be met by tributary flows or spills.
- When to use - each flow rule can have a ‘trigger’ specified, whereby for each day of the record, the trigger is checked against some relevant time series (such as storage volume) in order to set the flow rule to be on. This allows switching between rules at runtime to reflect watering options during dry vs wet periods.
You can import and export flow rules using the relevant contextual menu items (as shown in Figure 1).
Each rule also consists of a condition tracker, which is used to turn rules on and off. If the condition tracker falls bellow a threshold, the rule is turned on. If the condition tracker is above a threshold, then the rule is turned off. Only one condition tracker can be defined for a collection of rules. However, each individual rule can have its own threshold that decides when the rule is turned on. The condition tracker can be used to represent a multitude of environmental or accounting rules that turn flow rules on and off. Examples of using the condition tracker are:
- Representing the ‘health’ of an environmental asset; or
- Representing environmental rules that turn on and off when an account balance exceeds a certain level.
Rules can also be grouped using the Category hierarchical item.
Flood/fresh
The most common type of flow requirement is a flood/fresh which defines a flow requirement above a set level. Figure 4 shows the parameters for defining this requirement.
Figure 4. Environmental Demand node, Flood fresh
Flow pattern
You can create a temporally varying rule by simply defining the pattern of the flow required as well as a trigger condition. The trigger condition will be either a set start day or a flow threshold which has to be reached.
Figure 5. Environmental demand node, Flow pattern
Minimum flow rule
The objective of this rule is to maintain a minimum flow in the model to maintain minimum habitat requirements, such as where flow should be kept above a certain limit for particular periods of the year.
Figure 6. Environmental demand node, Minimum rule
Translucency
This rule allows you to define conditions (in the Condition item| Season:
[IT1] : [IT2] : | 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: | Action could include a number of independent spells. |
| Minimum interval between planned spells: | only relevant in case the action consists of more than 1 spell. This is to specify the required period between spells to consider them independent spells. |
| Desired frequency: | Determines the desired return (or recurrence) interval. |
| Initial condition: | This is to determine the initial condition 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. |
| Allow orders: | If this box is not ticked, the flow node will only record (natural/unregulated) success of the actions. It will not place any orders. |
| Allow forcing of spells: | Turn this on if the flow node should try to force an action without the flow trigger being met. |
| Number of season failures before forcing | When the tick box above has been turned on, the user needs to specify after how many unsuccessful seasons the EFN should start forcing the action. This would usually be a longer period than the return period (e.g. if an event is desired 1 in 3 years, you may want to force after 5 unsuccessful years). |
| Time since last successful spell | : This is to initialise ‘Time since last successful season’ (so that initial Antecedent Condition can be determined). |
| Time since last successful spell in a successful season | This is to initialise ‘Time since last successful spell’ (so that initial Antecedent Condition can be determined. |
Spell Definition
Figure 3. Spell Definition menu
Figure 2. Spell Based Action menu
Success Criteria
Figure 4. Spell Based Action Success Criteria Menu
Rise and Fall
Figure 5. Spell Based Action Rise and Fall Menu
Translucency Action
This action allows you to define conditions (in the Condition item) where flow would be allowed to pass through a storage or restrictions be placed on extraction in an unregulated system. It does not require an augmentation method as orders will be determined based on the inflows to the storage for the current time-step, and hence no forecasting is required.
Figure
76.
Environmental demand node,Translucency
Working with flow rules
Grouping and prioritising
Flow rules can be grouped into categories. The default category is selected using the contextual menu.
| Info | ||
|---|---|---|
| ||
| Note: In the default category, every flow rule within the category is considered at each time-step. In any other category, only one rule within the category can be considered at any one time. Rules are prioritised in the order in which they appear in Source. For example, in Figure 8, the Flood/Fresh rule will have a higher priority than the Minimum rule. |
Rule dependency
You can specify whether one flow rule will depend on another using the Add Rule Dependency button in the Flow Rules hierarchical item list. Figure 8, for example, shows that Flow Pattern Rule #1 will only come into effect when Minimum Rule #2's condition has been met.
Figure 8. Environmental demand node, Rule dependency
Action Menu
