Page Comparison

Introduction

The Environmental Demand Model (EDM) operates on a daily basis generating demands and supplying water to meet these demands via the water user and supply nodes. It provides a way of capturing simulating environmental water (flows) requirements in Source. These requirements may be directed at in-channel and/or floodplain habitats, communities and ecosystems, effectively by generating 'environmental demands' in a manner analogous to other water user demands in Source.

Environmental water (flows) requirements are captured represented in the EDM as ‘flow rules’. The aim of the model is to specify a A flow rule set that will generate the water required to achieve predefined environmental flow objectives. This model can be applied in both regulated and unregulated systems.As noted, the EDM can be set up as either /requirements. These requirements may be directed at in-channel and/or floodplain habitats and ecosystems.

The EDM can be configured in two ways: as an in-stream requirement on a main channel link (refer to In-stream requirement for details on configuring the node this way) or form part of as a 'floodplain demand' on a branching link via a splitter (refer to Floodplain).  An

It is important feature to note is that an EDM set up as an in-stream requirement could include 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 would often be the way in which environmental water requirements for floodplain ecosystems are specified ie. according to flow requirements for the main river channel, that are based on known hydrologic linkages with the floodplain (eg. 25,000 X ML/d for 14 day durationY days duration to ensure inundation of floodplain wetland Z).  

The difference is that An EDM node configured on a floodplain -configured EDM branch orders water without considering according to the flow hydrologic characteristics of the main river channel.  It does this that branch - by specifying a flow rate or volume a point in the branching channel connecting to the floodplain.  In this situation, there may also be an environmental water  'account' to which the ordered water can then be debited.branch - with the splitter specifying the hydrologic relationship with the main channel (via a ratings table or curve).

Double-click the node to open its feature editor, shown in Figure 1. If you have an account configured (using the Resource Assessment Explorer), you will be able to enable or disable Account Distribution using the contextual menu shown.

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.

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:

• Baseflow - specifies a minimum flow, usually applied to maintain minimum habitat requirements;
• High Flow/Flood - 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
• Pattern - specifies a pattern of flow, used to define multi-peak events.

Common elements of each of the four rule types that need to be configured 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 and 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 2 shows the parameters for defining this requirement.

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 3. Environmental demand node, Flow pattern

Minimum 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 maintained above a certain limit for particular periods of the year. Figure 5 shows the parameters that must be specified for minimum flow.

Figure 4. Environmental demand node, Minimum rule

Translucency

This rule allows you to define conditions 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 5. Environmental demand node, Translucency

Grouping and prioritising

Flow rules are grouped into categories and you can create as many categories as they wish. You can select which category will act as the default one using the contextual menu. Note that in the default category, every flow rule within the category is considered at every 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 1, the Flood/Fresh rule will have a higher priority to 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 6, for example, shows that Flow Pattern Rule #1 will only come into effect when Minimum Rule #2's condition has been met. 

Figure 6. Environmental demand node, Rule dependency

Condition

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.