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.
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.
Figure 1. Environmental Demand node
Reference
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, Reference
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) 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 7. 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
The Environmental Flow Node (EFN) is designed to simulate environmental flow requirements according to a set of rules. These rules are described through a set of actions, that aim to capture the environmental flow requirements at a particular location within the river system. The actions can be used to define both in-stream and overbank water events. However, in the case of overbank watering events, other nodes (such as a loss node or flow split) will be required to remove any water from the river reach.
The EFN provides a means of capturing the shape of flow events that an environmental water manager may wish to create. These definitions of watering patterns are captured as ‘actions’ within the EFN. Two types of actions are available at the EFN. These actions have been designed to capture the commonly defined environmental flow requirements specified in environmental flow studies and water regulations. These actions allow you to construct a flow regime at a location using of a combination of actions. The two types of actions available are:
- Spell based actions allows you to define a period that the flow has a set of desired characteristics. This type of action can be used to specify a range of event types such as baseflows, fish nesting events, and small to large flood events.
- Translucency actions allow you to specify the flow requirements in terms of some other time series, usually the release from a dam based on the inflow of the dam.
By setting a combination of different actions, you can describe a desired flow regime at a given location in the river system using the environmental flow node's feature editor.
How the environmental flow nodes interact with other components of your river system model such as the environmental flow manager (EFM) and resource assessment system is described in the Scientific reference guide. The user guide highlights when the node's behaviour will differ depending on if the environmental flow node is used as a stand-alone node or if it is used in conjunction with an EFM and a resource assessment system.
Setting up the EFN
How you setup the environmental flow node will depend on if you are using the node in conjunction with a resource assessment system and environmental flow manager.
Double-click the EFN to open its feature editor, shown in Figure 1. The EFN feature editor allows you to specify the following:
- Specify maximum account deduction. Note: this will only impact on the model if the EFN is used in conjunction with a resource assessment system and the EFM
- A set of actions that will determine how the environmental flow node tracks events and/or orders water to deliver a particular flow regime. Actions are added by right clicking on “Actions” and selecting “Add new action”. You can then choose to add a new Spell Based Action or Translucency Action.
Specify maximum account deduction allows you to specify a limit to water debited to an accounting system. If this deduction cap is more than the total volume ordered, the total order is debited. This parameter can be specified as a value or a function. This parameter only applies when the EFN is used in conjunction with the EFM.
By default, the model will account for the volume of EFN orders (on top of the downstream order). 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.
Adding an Action
To add an action, you right click on the top action menu item. You can then choose to add either a Spell Based or Translucency Action (Figure 1). You can add multiple actions to a single node. The actions will work together to determine a total requirement for each timestep.
Right clicking on the action title allows you to rename, add/edit note, delete or enable/disable the action.
Figure 1. Environmental Flow Node
Defining a spell-based action
Spell based actions allow you to define the characteristics of a flow event, the pattern of their occurrence, 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.
Ordering of actions can be separated from the observation of actions using the Spell Observer functionality.
When the Spell Observer functionality is enabled, some elements of the interface become redundant
When the Spell Observer is enabled, the following parameters/functionality become redundant.
|
|---|
Figure 2. Spell Based Action menu
| Menu Item | Description: without observer functionality enabled | Description: with spell observer functionality enabled | ||||||
|---|---|---|---|---|---|---|---|---|
| Season | Period in which action is required (this is to specify a season within a year, the year specified has no relevance). | This period is for ordering the spells required to complete a successful season. You can define a separate period for observation in the Spell Observer set-up. | ||||||
| Number of spells in season | An action could include a number of independent spells. If you are including multiple spells within a season, be sure to check the "Number of spells required for success" (see Success Criteria screen). | An action could include a number of independent spells. If you require multiple spells for a successful season, be sure to set the "Number of spells required for a successful season" in your Spell Observer set up. | ||||||
| Minimum interval between forced spells: | This is relevant for any ordered events when the actions require more than one spell in a season, not only for forced spells. When the spell is not forced (where the "Allow forcing of spells" is not ticked on), the parameter works in conjunction with the Spell End functionality on the Spell Definition screen. For example, if you need to have x days ("Duration required below threshold') of flow below a particular threshold ("End Threshold") for a spell to end (used to define spell independence), a second event will not be ordered until you have x days below a the threshold, plus the minimum interval between ordered spells. For a Forced Spell (where the "Allow forcing of spells" is ticked on), the Spell End functionality on the Spell Definition screen is ignored. The "Minimum interval between forced spells" is used to determine when the spells are ordered. | This is relevant for any ordered events when the actions require more than one spell in a season, not only for forced spells. The "Minimum interval between forced spells" is used to determine when the spells are ordered, but not for spell observation. | ||||||
| Determines the desired return (or recurrence) interval. In the case where the Environmental Flow Node (EFN) is managed by the Environmental Flow Manager (EFM), the desired frequency is used in the calculation of Antecedent Condition. The Antecedent Condition is used by the manager as part of prioritising 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. | |||||||
| Allow orders: | This is enabled by default. If this box is not ticked, then orders will not be placed. The EFN will only record (natural/unregulated) success of the actions. These non-ordering actions are not visible to the Environmental Flow Manager. | This is enabled by default. If this box is not ticked, then orders will not be placed. The EFN will use the Spell Observer functionality to record natural or unregulated spells and seasons only. 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 trigger being met (i.e. it ignores the need for a threshold or direct order trigger). 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. When there are multiple spells in a season, the End Spell Functionality is ignored with the forcing of spells. The minimum interval between forced spells, and the length of rise and fall phases are used to determine when the spells are ordered. | If this box is ticked, the flow node will attempt to force an action without the trigger as spell requirements being met (i.e. it ignores the need for a threshold or direct order trigger). 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. When there are multiple spells in a season, the minimum interval between forced spells, and the length of rise and fall phases, as well the difference between min and max travel time are used to determine when the spells are ordered. When Spell Observer is enabled, the "forcing" of Spells functionality uses the count of observed successful spells by the Spell Observer in its decision-making. | ||||||
| Number of season failures before forcing | If Allow forcing of spells has been selected, the user needs to specify after how many unsuccessful seasons the node should begin forcing the action. Orders will be placed for the spell once the number of unsuccessful seasons equals the Number of season failures before forcing When used with the EFM, orders will only be placed if the EFM has enabled the action. | If Allow forcing of spells has been selected, the user needs to specify after how many unsuccessful seasons the node should begin forcing the action. When Spell Observer is enabled, outputs of the Spell Observer will be used to determine the number of unsuccessful seasons. When used with the EFM, orders will only be placed if the EFM has enabled 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. | This functionality no longer works when the Spell Observer is enabled. It is recommended that "End Spell using a function" is used instead. | ||||||
| End Spell using a function | If "End spell using a function" is selected, the user can define a Boolean function that returns 1 (True) or 0 (False). The EFN will continue Ordering while the function returns 0 (false) and orders will be cancelled while the function returns value 1 (True). | |||||||
| 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. | |||||||
| 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. | |||||||
| 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. | |||||||
The following Note will appear on the interface if the Action is managed by the EFM. "Note: This action 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."
Spell Definition
Figure 3. Spell Definition menu
| Menu Item | Description: without observer functionality enabled | Description: with spell observer functionality enabled |
|---|---|---|
| Spell Start method | You can choose between a Threshold-based method or Direct ordering-based method to order a spell. | |
| Threshold | This will be enabled if you choose a Threshold-based Method in your Spell Start setup. Here, you can provide the threshold that the expected flow must equal or exceed for the spell 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. | |
| Direct Ordering | This will be enabled if a Direct Ordering-based Method is chosen in your Spell Start setup. A Direct Ordering-based method provides an alternative to using a threshold with the option to initiate spell-based actions controlled by function. You can use a function to define Direct Ordering that returns a True (1) or False (0) to indicate whether the spell should be ordered or not. Functions should be evaluated before the Order Phase. | |
| Natural Spell Start Threshold | This will be enabled if a Direct Ordering based Method is chosen in your Spell Start setup. The user needs to define a Natural spell start threshold in order to allow natural spell activities to be considered. | When Spell Observer is enabled, this functionality will be disabled. |
| 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 | Target flow rate that the Action will order. The user can implement a fixed flow rate, a data source, a function or a flow target table to determine a spell’s Target You can define a separate target for observation in your Spell Observer set-up. |
| Limit target to reference flow | Limit 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 successful spell, regardless of whether water has been ordered to augment it or not. | This duration is used for ordering a spell. You can define a separate duration for observation in your Spell Observer set-up. |
| 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 (1) or FALSE (0). 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. | This allows the ordering 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 (1) or FALSE (0) or use a function to evaluate whether the spell can be extended. The function should evaluate to TRUE (1) or FALSE (2). Spell Success will be determined by the Spell Observer. |
| End threshold | A 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. | This functionality is disabled with the spell observer. |
| Duration required below threshold | This 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. | This functionality is disabled with the spell observer. |
| Anchor | ||||
|---|---|---|---|---|
|
When the Spell Observer is enabled, the success criteria on this screen are not used. Spell Success is determined by the parameters set on the Spell Observer Screen.
When the Spell Observer is not enabled, you 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 is 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
Target | 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. |
| Volume | Proportion 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 Season. Relevant in case of actions with multiple spells, where 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
Method: | Days, Rate (ML/d) or Percentage to define a spell’s rise and fall. For more details see scientific reference guide
|
| Rise: | Period, rate or percentage at which flow will rise from expected flow (Minimum Constraint) to the flow Target. |
| Fall: | 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. |
Spell Observer
The Spell Observer is designed to look for flow events regardless of whether you have ordered an event. This includes:
- The ability to look for events that occur outside the ordering window
- The ability to look for events that are based on the delivery of a specific volume of water during a particular season.
The "Enabled" option on the Spell Observer screen (Fig. 6) will be the key to switching between the non-Spell Observer and Integrated Spell Observer functionality. When the user enables the Spell Observer (clicking the enable check box on the Spell Observer screen), the Spell Observer functionality integrates with the action and changes the ordering behaviour.
Please note that enabling Spell Observer makes the following interface components redundant:
- Success Criteria Screen: With Spell Observer enabled, the criteria for success are no longer based on the Success Criteria Screen shown in Figure 4.
- End Spell if it will Fail Checkbox: Enabling Spell Observer overrides this function. The spell will not end based on this checkbox, and it is recommended to use the “End Spell Using a Function” option to stop ordering.
- Spell Definition>>Spell End Criteria: This no longer impacts spell ordering when Spell Observer is enabled.
- The Spell Definition > Start Spell > Direct Ordering Method > Natural Spell Start Threshold
The interface (Figure. 6) allows you to set the parameters that will determine the success of a spell (and the success of a season). These parameters can also be set via input sets.
The spell Observer does not consider rates of rise and fall when deciding if an event has been successful.
Figure 6. Spell Observer Menu
| Enabled | This option on the Spell Observer screen is the key to enabling Integrated Spell Observer functionality. If unticked, it will use the non-Spell Observer Functionality. |
| Season | This is a period during which the action is to be observed. If the “Use season defined for this action” is unchecked, the user can define the start and end dates of the observation season here. This period can be longer than the ordering period. |
| Use season defined for this action | If this box is checked, then the observer season will match the season defined for ordering on the Spell Based Action Menu. |
| Start target for observation | Target Flow rate for observation. If the “Use spell definition target” is unchecked, the user can define the flow rate here by either using value or function. If a function is used, the value will be set to the value of the function on the first day of the season each year. This target can be smaller than the one defined in the Spell Definition Menu. |
| Use spell definition target | If the box is checked, then the observer’s Start target for observation will match the target from the Spell Definition Menu. You won’t be able to check this box (it will be inactive) if the target has been defined as a Flow Table or Data Source or is limited to the reference flow in your Spell Definition Menu. |
| Minimum duration for observation | Minimum duration of the spell for observation. If the “Use spell definition duration” is unchecked, the user can define the duration here by either using value or function. If a function is used, the value will be set to the value of the function on the first day of the season each year. This duration can be smaller than the one defined in the Spell Definition Menu. |
| Use spell definition duration | If the box is checked, the Observer’s Minimum duration matches the Minimum spell duration defined on the Spell Definition Menu. |
| End target for observation | This is the flow threshold below which the flow should fall for a certain number of days (Duration below end target) to consider spell to be finished. If “Use start target for observation” is unchecked, the user can define the end target by either using value or function. If a function is used, the value will be set to the value of the function on the first day of the season each year. If the flow does not drop below the end target for observation, the spell will end when the season ends. |
| Use start target for observation | If the box is checked, then “End target for observation” will match the “Start target for observation”. |
| Duration below end target | This is the minimum duration for which the flow must remain below the “End target for observation” for the spell to be considered comple |
The parameters below in the observation screen define the success criteria. A spell is successful when all these criteria are met.
Proportion Required -Target | Proportion of Start target for observation that needs to be achieved to call an event a success. |
Proportion Required -Duration | The proportion of the defined Minimum duration for observation that needs to be achieved to consider a spell successful. |
Proportion Required -Volume | The proportion of total action volume that needs to be achieved to call an event a success. |
Number of spells required for a successful season | The number of spells required to achieve a successful season. Where the “Number of spells required for a successful season” exceeds 1, the season is considered to be successful when the required number of successful spells is met. When a season is deemed to be successful, the antecedent condition resets to one. It will reset to 1 for each subsequent successful spell in the season. |
| Anchor | ||||
|---|---|---|---|---|
|
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 7. Translucency Action Menu
Season: | 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. |
| Table of Contents | ||
|---|---|---|
|
Add or Edit Note
By right clicking on a heading, notes can be added or edited in three levels: (a) Top environmental flow level (e.g. Environmental Flow in Figure 8); (b) Individual Action level (such as Spell Based Action 1, or Translucency Action 1 in Figure 8) and (c) Function button level (any function button such as (1) in Figure 8 in Spell Definition, Success Criteria or Rise and Fall of a spell based action or any in Translucency action).
In the Note screen shown in Figure 8, you can define the note's properties using three icons; from section (2), add /edit the note in section (3), and delete the note with the bin icon. The selected property icon (i.e., info, warning and critical) will appear beside any items with that note for the information, even when the Note screen is closed.
Figure 8. Add/Edit Note
Note: For functions used in the Environmental Flow Node, if the function is using modelled variables relating to an action, any time of evaluation prior to and including environmental flow prioritisation can be used. If the function is using modelled variable relating to a group (e.g. group enabled or group cost), then environmental flow prioritisation must be selected for time of evaluation, and additionally, the modelled variable date range must be set to current iteration.
EFN Actions in the Feature Table
The parameters of the Environmental Flow Node (EFN) can be reviewed and edited from two separated elements in the Feature Table.
The node-level parameters, including the option to specify a Maximum Account Deduction can be reviewed and edited for all Environmental Flow Nodes using the Environmental Flow element of the Feature Table (Figure 9).
Figure 9. Environmental Flow element in the Feature Table
All Action-level parameters from all Environmental Flow Nodes in one scenario can be triggered from the Environment Flow Actions element of the Feature Table (Figure 10). Spell Based Action or Translucent Action in the left panel can toggle the relevant parameter details in the middle panel.
Figure 10. EFN Actions in the Feature Table
The Environmental Flow Actions in the Feature Table include both Spell Based Actions and Translucency Actions if applicable. All parameters defined in each Spell Based Actions and/or Translucency Actions can be reviewed and edited. Such parameters cover Spell Based parameters (Figure 2), Spell Definition parameters(Figure 3), Success Criteria (Figure 4), Rise and Fall parameters (Figure 5); and all Translucency Actions parameters(Figure 7).