Rules-Based Ordering (SRG)

Rules based ordering in Source is a method of simulating the process of water ordering that allows the modeller to explicitly specify rules that determine sources of supply and the paths used to deliver orders. It is designed to model the process by which a river operator makes choices as to how to place bulk orders on behalf of individual irrigators and other types of water user. In rules based ordering, the ordering system represents the river operator, and rules entered at Confluence nodes and Maximum Order Constraint nodes represent the operator’s decisions.

Source rules based ordering may be differentiated from heuristic ordering methods in other river modelling software (MSM, IQQM) by the following features:

• Orders are directed to the ordering system rather than a particular storage or supply source.
• In each model time-step an extra pass of the river network is done that identifies delivery constraints on each supply path. This informs the ordering pass as to the best supply path.

When choosing when to use rules-based or optimised ordering systems in Source, the following factors should be considered:

• Is modelling of ownership or off-allocation required? Rules based ordering is the only ordering method in Source that currently models these concepts.
• The model time-step. Rules based ordering performs well for a daily time-step as well as longer time-steps. A daily time-step may cause performance issues with optimised ordering, as the number of nodes in its solution network multiplies as the time-step reduces from monthly to daily unless travel times are short. Also, the optimised solution only considers inflows in the current time-step, so its solution may not be as efficient. If a longer time-step (such as monthly) is used, the optimised ordering system is likely to provide more efficient solutions than rules based ordering, with comparable performance.
• Is there perfect knowledge of future inflow to and losses from the supply system? Rules based ordering is better suited to situations where these factors are not known than optimised ordering, as it provides a method of forecasting.
• Are the "rules" known? If the rules that determine which supply path to use at various storage levels are well established, rules based ordering should be more efficient than optimised ordering. This is because it analyses the river network in two passes, while the optimised method may perform several passes to find a "solution" (supply path).
• Is the objective is to model what an operator does? If this is the case, rules based ordering should be used.

Rules based ordering applies to the entire river system represented in a modelling scenario. This type of ordering system operates over multiple time-steps, as it relies on forecasts of future inflow, loss and demand. Order tracking is performed at every node and link in the modelling scenario, and order volumes are reported for each time-step.

Several jurisdictions in Australia have developed software with heuristic models of water ordering, such as IQQM and MSM. Rules-based ordering in Source has been developed by eWater, using ideas from these earlier representations.

Heuristic models of water ordering have been used in river management for many years. The rules based method in Source is an extended version of these earlier models.

Source version 3.0.8.7

For a rules based ordering system to operate in Source, the "New rules based ordering system" option must be selected as the ordering algorithm. The modelled network must also contain:

• At least one point of demand. This may be represented as a Supply Point node connected to a Water User node with a Demand model configured, a Minimum flow requirement node, or a Storage node with an Operating Target entered; and
• At least one point of supply, represented by a Storage node or Off Allocation Sharing node upstream of the point of demand, connected to the demand location via one or more links and nodes.

In regulated sections of river, flow at any location is usually divided into the "regulated" quantity - the amount that has been released from a reservoir to meet downstream orders, and the remaining "unregulated" quantity. Part of the unregulated flow may then be available for "off-allocation" use - for example, flow above a given threshold. The reservoir is hence a regulated (ordered) water supply source, but the river itself at any given location may be an off-allocation source of supply. In Source ordering systems, these sources of supply are represented by Storage nodes (for reservoirs) and Off-allocation Sharing nodes (for locations in the river where unregulated water is assigned for off-allocation use).

A water order can be considered as a volume of water required at a location in a regulated river system at a specific time. In Source, these orders may be placed at one of the nodes described under Ordering Locations to meet a particular demand or requirement. There is also the concept of an "off-allocation request" - which represents a request to use the unregulated "off-allocation" water that may become available in the river at a particular location (see Sources of river water supply). Off-allocation requests are also tracked by the ordering system, but they differ from orders in that they are associated with a supply location (an Off-allocation Flow Sharing node). This is discussed more in the entry on Off-allocation Flow Sharing.

In Source, the Water User node is used to represents an individual , organisation or entity (such as the environment) that places water orders. The Supply Point node represents the location in the river that these orders are placed. In river operations, releases from upstream reservoirs are ordered so that downstream weirs and reservoirs remain within required operating ranges, or environmental flow requirements may be met. In Source, these concepts are modelled by the creation of orders at Storage nodes with an Operating Target, and Minimum Flow Requirement nodes.

Source uses a model component to manage and track orders for a rules based ordering system. Orders are placed to this component rather than an individual Storage node. This means that an order placed at any location may be supplied from any Storage node upstream of the ordering location, not just one immediately upstream - and on any path when there are storages on multiple upstream paths.

A regulated river system generally has a number of management rules that are used to maintain flow in the system within a range that ensures efficient delivery of water to downstream requirements. This flow range is bounded by a minimum requirement and a maximum capacity. Each node in a Source scenario river network that uses rules based ordering has a desired flow range associated with it. See Figure 68 for an illustration of this concept.

In Source the management rules are modelled using Minimum Flow Requirement nodes, Storage node outlets, regulated Splitter node effluent relationships and Maximum Order Constraint nodes. The desired flow range changes over time at each location, due to changes in rules, flow conditions, or when outlet or channel capacities are reached. In future versions of Source, each location’s desired (or target) flow range will also take into account the impact of upstream water user demand.

The rules based ordering system requires an estimate of the time taken for an ordered volume of water to travel from points of supply to each ordering location so that it can choose appropriate supply paths and time storage releases correctly. This time estimate is referred to as the "order time".

For example, water is estimated to take 4 days to travel from an upstream reservoir to the location where it is to be extracted, so to receive the required water order when desired, the water order needs to be placed four days in advance to account for this. The extraction location’s "order time" is 4 days.

The order time estimate is based on the average travel time of water in each river reach between the supply source and the ordering location. The modeller enters parameters used to determine order time into each link’s Feature Editor - Routing interface (Av. Reg. Flow and Reach Length).

When there are multiple paths to storages upstream of an ordering location, or multiple storages on the same supply path, there may be multiple possible order times for that location. In such cases a water order may be able to be met within a range of order times bounded by a minimum and maximum. This is referred to as the "order period". The rules based ordering system determines the minimum and maximum order times for every node and link in the modelled river network at the start of the modelling scenario run (order times do not change during the run). A Confluence node will have two sets of order times if it has two regulated inlet branches.

In scenarios where there are multiple reservoirs in series and/or multiple possible supply paths, releases are scheduled to ensure water arrives at downstream locations at the appropriate time, in a way that allows management rules to be met and the system to operate efficiently.

To ensure there is enough water stored at a storage node to supply downstream orders, the stored volume of water over the (future) order period is estimated. Orders are placed to upstream reservoirs to fill any shortfall between the storage’s forecast volume and its target operating level (which has been defined by the modeller). Forecasts of storage inflow and net evaporation specified by the modeller are used in this process.

In the case of multiple supply paths, the time required to supply water on each path (the forecast order period) is likely to be different. The rules based ordering system makes adjustments at Confluence nodes to cope with this:

• Where one inlet branch’s order to be delivered in a future time-step is still outstanding (awaiting release), but the other branch’s order for that time-step has been released, the outstanding order is adjusted to take into account the water already on the way from the other branch. This situation occurs when upstream branches have a different minimum order time.
• Where one inlet branch’s order is due for release from an upstream storage but the other is not as yet, the amount of water to be supplied from the other branch is forecast and taken into account when determining the order due for release in the current time-step. This situation occurs when upstream branches have a different maximum order time.

When ownership is enabled in Source, every water order is associated with an owner and is generally supplied using that owner’s water. Where there is insufficient water to supply an owner’s order at any location, and another owner has water surplus to their requirements, the owner with a deficit may borrow water from the owner with surplus to help meet demand. This is discussed in more detail in this guide’s entry on Borrow and Payback.

In Source, one or more water owners operate within the boundaries of an Ownership System, marked by "boundary" Transfer of Ownership node(s) and the upstream and downstream ends of the modelled river network. Where there is more than one Ownership System, the modeller can choose how orders are to be handled at the boundary Transfer of Ownership node(s):

• The modeller can specify that orders can be supplied from outside the Ownership System (the default option). The original downstream order is split between the new upstream owners in Order proportions specified by the modeller at the boundary Transfer of Ownership node, and supplied using water belonging to the specified upstream owners. When flow resulting from the released order reaches the upstream boundary of the ordering location’s Ownership system, its ownership is split between downstream owners according to Flow proportions specified by the modeller at the boundary Transfer of Ownership node. It is entirely possible that the split of orders due at the Ownership System boundary at any time-step will not match the flow proportions. The Borrow and Payback system rectifies this situation, hence allowing the most efficient use of the available flow.
• Alternatively, the modeller can specify that orders are only to be supplied from Storage nodes within the boundaries of the ordering location’s Ownership System (ie by specifying 0% transfer to upstream owners in the Order proportions). For simplicity, Source does not currently take Ownership System boundaries into account when determining maximum order times. The maximum order time for any modelled location is always the longest average travel time of flow between the location and an upstream Storage node.

There are also "in-system" Transfer of Ownership nodes at which the modeller may specify the transfer of ownership of orders and flow between owners in the same Ownership System. See Ownership Systems for more information.

The rules based ordering system maintains a list of orders due over the order period at each model element (node and link) on regulated paths in the scenario river network. This list is updated in the ordering phase of each time-step. When ownership is enabled, a separate list is maintained for each owner.

In every model time-step, there is one entry in the order list for each future time-step in which a volume of water ordered downstream in the current time-step is due to arrive at the location. The first entry is for the order due for delivery in the minimum "order time" , ie the earliest time-step at which water could be delivered to the location if it was released from an upstream storage in the current time-step. The last entry in the list is for the order due in the maximum "order time", ie the latest time-step at which water could be delivered to the location if it was released from an upstream storage in the current time-step. If there are no orders due to be delivered to the location within its order time window, its order list will be empty.

Order lists are processed in the order phase of a time-step. At each model element, list entries are passed to the next element upstream after the associated volume of order is adjusted to cater for:

• Gains (tributary inflow at an Inflow node, unregulated inflow to a Confluence node, lateral inflow to a Routed link, return flow from a water user node, rainfall)
• Losses (at a Loss node, unregulated outflow from the effluent at a Splitter, lateral flow loss at a Routed link, evaporation)
• Rules (target level for a storage node, storage/splitter outlet constraints, minimum flow requirement, maximum order constraint, confluence branch priority/ratio)

The model time-step to which each order list entry refers effectively goes "back in time" between a downstream node and an adjacent upstream one by the average travel time of the link that joins the nodes. This is illustrated in Figure 69 under Propagation of orders and constraints.

The rules based ordering system attempts to keep flow within the desired range at each model element on a regulated path in the scenario river network using a list of constraints. Like the order list, in every model time-step, the constraint list contains an entry for each future time-step in the order period, and a separate list is maintained for each owner. Each entry in the list contains the desired flow range, expressed as a minimum and maximum constraint value. The flow range reflects the combined impact of all constraints on flow between the modelled location and the closest upstream storage on all possible supply paths.

The constraints list is used at a Confluence node in the ordering phase of each time-step. The constrained flow range on each inlet branch over a future time-step determines how much of the downstream order for that time-step is assigned to the branch/supply path. The list is updated in a "constraint phase" prior to the time-step’s ordering phase so it may be referenced in the ordering phase.

There will be a difference between modeller specified forecasts and modelled flows. This, plus the use of expressions for gains and losses means that the forecast constrained flow ranges in the constraint list cannot be completely accurate. For this reason the maximum values from the constraint list are not used to constrain orders placed at ordering locations. Instead, a "constraint factor" list is used to address cases where the flow delivered is less than that ordered. This list in essence represents the river operator informing water users as to operational constraints that will result in orders not being met on a given day.

There is a constraint factor list for each owner at each model element. At every model time-step this list contains an entry for every time-step from the current one to the minimum order time. The constraint factor represents restrictions on ordered flow that have already been incurred upstream. Demand models use the constraint factor to readjust the volume of water they expect to receive and then may place new or increased orders to compensate. This is discussed in this guide’s entries related to the supply point node and water user node.

Both the order volume and flow volume must be known at each model element to determine the time-step’s constraint factor, so this calculation is performed after the time-step’s flow phase. The constraint factor list is propagated from upstream to downstream.

Where there is only one supply path, and the upstream node is not a storage, the length of the future time window covered by the order and constraint lists does not change between nodes. In these cases, list entries are updated before the list is passed directly to the adjacent model element (downstream for constraints, upstream for orders). The model time-step to which each list entry refers effectively changes by the average travel time of the link that joins the nodes.

Constraint factor lists behave differently to other ordering system lists as they refer to time-steps from the current one to the start of the order period. Hence the length of the constraint factor lists changes between adjacent nodes by the average travel time of the link that joins the node. Entries that refer to future time-steps at the downstream node are copied from the upstream node. At Storage, Splitter, Maximum Order Constraint and Transfer of Ownership nodes the current time-step’s constraint factor is determined at that element in the time-step. At other types of model element, it was passed from upstream n time-step’s previously, where n is the time-steps of travel time from the adjacent upstream node. This is described further under the Flow phase section of Processes.

At a Storage node the order period changes, as the supply source for the minimum order time changes to the next Storage node upstream. The constrained flow range is set to the flow range permitted by the Storage node’s outlet path for the relevant time-step. Similarly, the constraint factor is the fraction of the order due that is released in a time-step. Order volumes to pass upstream are set to the amount required by the storage node to keep it at its target volume/level.

The way lists propagate up/downstream where there is a single supply path is illustrated in Figure 69. Propagation of ordering system lists up/down a single supply path in a time-step. The set of boxes next to each node name represents the entries for future time-steps that will be in the node’s ordering system lists. The upstream and downstream version of order and constraint lists are illustrated for the Storage node where the order period changes. Note that the downstream order list at a Storage node also represents the regulated release due in the time-step illustrated.

At confluence nodes with two upstream supply paths (ie with Storage nodes on them), the order period covered by each of the upstream branches/paths may be different, and can overlap. This means that each owner’s order, constraint and constraint factor lists need to be split/merged:

• Constraint lists from each upstream supply path are merged to form the downstream list. This new list contains entries for future time-steps from the earliest minimum order time to the latest maximum order time of both upstream branches. Constraint factor lists from upstream branches are also merged. The downstream constraint factor list covers the period from the current time-step to the earliest minimum order time of both upstream branches.
• The downstream order list is split to form a new order list for each upstream supply path, each upstream order list covers the corresponding path’s order period. The proportion of the downstream order volume assigned to each of the upstream paths for the corresponding time-step is determined by a combination of the constrained flow range and rules specified by the modeller.

More detail on how constraints and orders are processed in multiple supply path situations is given under the Confluence node heading in each of the time-step’s phase sub-sections.

When the model is initialised, the modelled river network’s supply paths are identified, and the minimum and maximum "order time" is calculated for every node. The process starts at each node at the head of the river network (ie node with no inlet connection). The head node is the start of a path. There is no particular order in which head nodes/paths are processed - but the modeller can specify that the sequence be reported.

Constraint factor lists for every owner at each model element are also created at this stage. There is an entry for each time-step from the current one to the minimum order time. Every constraint factor value is set to 1.

Each path is processed from upstream to downstream. The path’s minimum and maximum order times at its head node are zero. The sequence of nodes and links on the path are saved as they are encountered for use during the model run. The steps that are performed at each type of network element encountered when processing a path are described below:

The link’s average travel time is added to the path’s minimum and maximum order time totals, then the downstream path is processed.

At a Confluence node:

• If the path being processed is regulated, its minimum and maximum order time are saved.
• If there is another path/inlet branch connected to the confluence node, and the other path has not been processed yet, processing of the current path is exited.

The following steps are performed once both paths upstream of the confluence have been processed:

The confluence’s minimum order time is set to be the smallest value of minimum order time of both upstream paths.

• The confluence’s maximum order time is set to be the largest value of maximum order time of both upstream paths.
• If either of the upstream paths are regulated, the confluence node is marked as regulated.

At Storage and Off-allocation sharing nodes:

• The minimum order time is set to zero.
• The maximum order time is set to the current maximum. Future versions of Source: If the storage is a weir, the average travel time for the weir’s upstream reach will be added to this maximum.
• The path the node is on is marked as "regulated".

If the path the node is on is regulated, its current minimum and maximum order time are saved at the node, then every downstream path is processed.

 In this phase each Supply Point node’s water user demand is calculated (based on information specified by the modeller at the connected Water User node).

The constraint phase precedes the ordering phase of every model time-step. In this phase, every path through the modelled river that was identified in model initialisation is processed from upstream to downstream. The steps performed at each node are:

• If there is no constraint list at a node (ie it is at the head of the river network), one is created with an entry for each time-step between minimum and maximum order time. If there are multiple owners, a list is created for each.
• The constraint list is updated if necessary. This is done as per the descriptions in following sub-sections. Where the model element type is not described, the constraints are not updated. Note that constraints are not currently updated for links - so a link’s constraint list will be the same as the one for the upstream node (or Splitter/Storage outlet path if it is connected to this). In future versions of Source, constraints will be adjusted for lateral flows on routed links.
• The constraint list is passed to the next model element downstream.
• An example of the values that may be contained within each entry of each node’s downstream constraint list is given in Table 63. This illustrates that as the list moves downstream, list entries are shifted forward in time the number of time-steps between nodes, and values in entry are adjusted. At the Storage nodes, the list is reset, and values represent storage constraints alone.

At an inflow node in any future time-step the downstream flow range equals the upstream flow range plus forecast tributary inflow volume for that future time-step. The downstream constraint list is generated as follows:

For each of the future time-steps ft between t+minOT and t+maxOT:

If ownership is not enabled, a single "not specified" owner is assigned the total forecast tributary inflow. In other cases, the current time-step inflow share is used to determine the owner’s share of forecast inflow in any future time-step. See for more details.

For each owner o:

Equation

At a loss node in any future time-step the downstream flow range equals the upstream flow range minus the loss volume for that flow range. The downstream constraint list is generated as follows:

For each of the future time-steps ft between t+minOT and t+maxOT:

1. The range of possible loss for future time-step ft is determined by applying the loss function to the upstream constrained flow range:

Equation

2. The minimum and maximum possible loss is shared between owners.

• If ownership is not enabled, the "not specified" owner has the whole loss.
• If fixed owner sharing rules specified, owner shares of loss may be specified by the modeller, or "murray style" (fixed to a specified threshold, then proportional). See Ownership for more details.
• If proportional owner sharing rules are specified:

Equation

3. The downstream constraints are then determined for each owner o as the difference between their upstream constraints and loss:

Equation

Currently the constrained flow range is not adjusted at a Supply Point node. In future versions of Source, the flow range downstream of a Supply Point node will be set to the upstream range minus the Supply Point’s demand, calculated in a new phase before the Constraint Phase. The Supply Point’s processing will therefore be similar to a Loss node. However, owner shares of the demand will be dictated by the modeller’s Distribution settings at the connected Water User node.

At a Splitter node, constraint values are updated in a similar fashion to the loss node, where effluent flow is treated as a loss from the main flow. The difference is that two downstream constraint lists (per owner) are created if there are two regulated downstream links connected to the splitter node. Also, the effluent outlet may be regulated, so for any given upstream inflow a range of effluent outflow values is possible.

• One (regulated) link downstream: Currently the constraint list is not changed, just passed downstream.

In future versions of Source, this type of Splitter Node will be processed in the same way as a Loss node - with flow down the unregulated downstream link being treated as the loss. To do this for each of the future time-steps ft between t+minOT and t+maxOT:

1. The range of effluent flow loss will be determined using a combination of the upstream constrained flow range, and the modeller specified relationships between upstream flow and effluent minimum and maximum flow:

Equation

2. Loss node steps 2 and 3 will be used to share the loss between owners, then determine each owner’s downstream constrained flow range on the main (regulated) channel.

• Two regulated links downstream: A constraint list is created for each path downstream, Main and Effluent.

For each of the future time-steps ft between t+minOT and t+maxOT, the following is done:

1. The effluent channel constraint for future time-step ft is determined by applying the effluent minimum and maximum flow relationships to the upstream constrained flow range:

Equation

2. The effluent channel constraints are shared between owners:

If ownership is not enabled, the "not specified" owner has the whole constraint range.

• If fixed owner sharing rules specified, MinEffluent, MaxEffluent, MinEffluentForMax, are passed to ownership processing. Owner shares of effluent flow may be fixed (specified), or "murray style" (fixed to a specified threshold, then proportional). See for more details.
• If proportional owner sharing rules are specified, the effluent constraint range for each owner o is:

Equation

3. The main channel constraints are then determined for each owner o as the difference between their upstream and effluent constraints:

Equation

At a confluence node the downstream constrained flow range for a future time-step is the sum of the upstream constrained flow range for regulated upstream branches in that time-step, plus the sum of forecast inflow volume from unregulated upstream branch(es) in that time-step.

The upstream constraint lists for regulated branches of a confluence are processed first to create a downstream constraint list. Then, if there is an unregulated branch, forecast inflows on this branch are used to adjust the downstream constraint list. Note that if both branches are unregulated there will be no list of constraints to process.

The following steps are performed for each owner o (or the "not specified" owner if ownership is not enabled):

• If two upstream branches are regulated a new downstream constraint list is created that extends the time period covered by the constraint list arriving from both upstream branches so that it covers the entire Min-Max order time of both branches. The min and max constraint values represent the combination of constraints on both upstream branches.

1. The latest maximum order time (maxOT) is determined, and the upstream branch with the earliest maximum order time (shortB) is identified.

2. The shortB branch constraint list is extended forward in time so that it covers the period to the latest maximum order time maxOT. The min and max constraint values in the new entries are set to equal those for the time-step that was previously the last covered by shortB list.

3. The earliest minimum order time (minOT) is determined, and the upstream branch with the latest minimum order time (shortB) is identified.

4. The shortB branch constraint list is extended back toward the current time-step to incorporate the earliest order time time-steps for both branches. The min and max constraint values for the new entries are determined based on constrained previous orders due in the time-step they represent:

For diff = 0 to MinOrderTime(shortB) - minOT - 1

Equation

5. The constraint lists for both upstream branches are combined to form the list passed downstream. The downstream min and max constraint values equal the sum of the upstream branch values for the corresponding time-step:

For ft = t+minOT to t+maxOT

Equation

• If only one upstream branch b is regulated the downstream constraint list is copied directly from the regulated branch’s constraint list.

Equation

• If the Confluence also has an upstream unregulated branch, inflow from this branch is forecast and added to the regulated flow range to get the desired range of flow downstream of the Confluence node:

For ft = t+minOT to t+maxOT

Equation

As with the inflow node, the current time-step inflow share is used to determine the owner’s share of forecast inflow in any future time-step. See Ownership for more details.

Constraints are reset at the Storage node. The constraint list(s) for each downstream outlet path have an entry from minimum to maximum order time that reflects the possible release range from the storage at its volume in the current time-step.

If ownership is enabled the modeller can specify whether the outlet path is shared according to fixed percentage or proportional to storage volume. The outlet path constraints are shared in the same way.

For each outlet path p:

Equation

For each owner o and in every future time-step ft = t+minOT(o) to t+maxOT(o)

Equation

At a Minimum flow requirement node, the base of the constrained flow range for any future time-step is raised to the level required at this node (ensuring the maximum constraint is at least the minimum constraint). If there are multiple owners, the minimum flow constraint is shared according to the owners share of the upstream minimum constraint.

Where an expression is used to define minimum flow requirement, the current time-step’s evaluation is used to adjust constraints for all of the future time-steps in the order period.

For each of the future time-steps ft between t+minOT and t+maxOT:

Equation

For each owner o:

Equation

When ownership is not enabled, the Maximum order constraint is specified by the modeller as a value or expression - described here as function fMaxOrder(). When ownership is enabled, the modeller will have specified a the maximum order constraint via a table of volume expressions for each constraint/owner sharing level . The expressions are described here as the function fMaxOrder(level). See the description for the Maximum Order Constraint node under Input Data, and Figure 71 for more information.

Where an expression is used to define maximum order constraint, the current time-step’s evaluation is used to adjust constraints for all of the future time-steps in the order period.

The maximum order node steps are:

For each of the future time-steps ft between t+minOT and t+maxOT:

1. If ownership is enabled, constraint volumes at each level are checked to ensure they are non-negative, and increase from the previous level. An error is logged if this is not the case. This check is necessary during the scenario run as expressions can be used to determine level volumes in each time-step.

2. The maximum order constraint for this node is determined:

• No ownership - o is "not specified" owner: MaxOrder(o) = fMaxOrder()
• Ownership is enabled (fMaxOrder(0) = 0):

For each owner o

Equation

3. Values in the constraint list are adjusted for this node’s maximum order constraint:

For each of the future time-steps ft between t+minOT and t+maxOT and every owner o, the upper bound of the constrained flow range is limited to the maximum order level at this node (ensuring the maximum constraint is at least the minimum constraint):

Equation

At a Transfer of ownership node upstream owner constraints are transferred to downstream owners in proportions specified by the modeller. The total upstream constraint volumes are transferred.

For each of the future time-steps ft between t+minOT and t+maxOT:

Every downstream owner do is assigned the sum of constraint volumes transferred to that owner from all upstream owners in time-step ft:

Equation

In every time-step, the rules based ordering system performs an upward pass to calculate the total volume of order required at each modelled location in order to meet downstream demand. These calculations take into account forecast inflows and losses.

As described under Order tracking, each owner will have a list of orders at each model element , with an entry for each time-step between its minimum and maximum order time. A version of the order list arrives at the node from "downstream", is adjusted as required, then is passed upstream. The adjustment usually involves changing volumes ordered, but at some node types (Splitter, Confluence, Storage) it also involves merging, splitting or resetting the list.

Every path through the modelled river that was identified in model initialisation is processed from downstream to upstream to determine the total volume of order required per owner at each location over the future order time period.

The steps performed at each model element are:

1. If there is no order list at a node (ie it is at the downstream end of the path), one is created with an entry for each time-step between its minimum and maximum order time.

2. The model element’s list of orders and off-allocation requests is updated. The way in which the order list is updated at specific types of model element is described in the following sub-sections.

3. If the model element is a Storage node, the storage release is generated. Release details are saved to a list of releases for future reference.

4. Order and off-allocation request lists are recorded.

5. Orders and off-allocation requests are passed to the model element upstream.

6. Post order phase expression editor variables are calculated.

At the Supply point node, additional orders and off-allocation requests generated by the connected water user node enter the scenario river network. The steps are:

1. A list of regulated orders for each owner RegulatedOrder(o,minOT..maxOT) is created from the orders generated by the water user demand model in the current time-step.

2. Each owner’s anticipated extraction volume is determined based on the water user’s regulated order placed in the current time-step for delivery in time-step t+minOT.

3. The list of off-allocation requests for each owner is created based on the water user demand model’s opportunistic orders required to be delivered in time-steps after t+minOT.

4. If the supply point is NOT a groundwater node, the over-order volume is added to the total regulated order for each future time-step:

For ft = t+minOT to t+maxOT

Equation

5. The over-order volume is added to the total off-allocation request for each future time-step. See this guide’s entry on off-allocation flow sharing for more information as to how these requests are processed.

6. The volumes of orders in the RegulatedOrder list are added to the amounts in the ordering system’s upstream version of the order list for the corresponding future time-step:

For ft = t+minOT to t+maxOT and each owner o:

Equation

7. A copy of the order lists is saved at the water user for use in the flow phase.

Routed links may gain or lose water due to rainfall, evaporation and groundwater (seepage) as flow does not travel from one end to another instantaneously. The modeller can choose which of these lateral fluxes the rules based ordering system takes into account. The order coming into this routed links is adjusted to cater for the lateral fluxes selected by the modeller over each time-step that the ordered flow spends in the link. The lateral flux functions return flux volumes for the whole link. Hence, to avoid double counting, the order adjustments are divided by the link’s "travel time".

The rules based ordering system does not forecast changes in link storage volume over the order period (as it does at the Storage node). This means that where there are significant jumps in the volume ordered, there may be insufficient water stored in the link to achieve the required downstream flow to meet orders.

The way in which the owner’s share of each flux is determined is described under this guide’s entry for  Ownership at Nodes and Links.

LinkTravelTime =Max(1,DownstreamMinOT - UpstreamMinOT)

For each of the future time-steps ft from t+minOT to t+maxOT for which an order exists at this link:

For each time-step tt from 1 to LinkTravelTime, and every owner o

a. If net evaporation is to be taken into account, the forecast model to use is specified by the modeller. The surface area is determined by the ordered flow. Function fSurfaceArea(flowRate) has been derived from the modeller specified reach length and relationship between flow and reach width:

Equation

b. If flow based flux is to be taken into account:

EstimatedFlowFlux(o) =
Share(o) •
fFlowLossRate(t, DownstreamOrderTotal(ft)/dt) •
dt /
LinkTravelTime

Note that owner share Share(o) is determined in a similar way to losses at a Loss node.

c. If time series flux is taken into account, the current time-step’s flux rate is referenced:

EstimatedTimeSeriesFlux(o) =
Share(o) • fTimeSeries() • dt / LinkTravelTime

d. If groundwater (seepage) is taken into account, a forecast model to use is specified by the modeller. This uses level, which is determined by the ordered flow:

Level = fLevel(ft+tt, DownstreamOrderTotal(ft)/dt)

EstimatedSeepage(o,ft) =
Share(o) • fInfiltrationRate(Level) • dt/ LinkTravelTime

e. The order is adjusted for the total of the fluxes determined above:

EstimatedLateralFlux(o) =
EstimatedNetEvaporation(o) +
EstimatedFlowFlux(o) +
EstimatedTimeSeriesFlux(o) +
EstimatedSeepage(o,ft)

UpstreamOrder(o,ft) =
DownstreamOrder(o,ft) + EstimatedLateralFlux(o)

At an Inflow node the order volume for each of the future time-steps in the order period is reduced for forecast tributary inflow volume for that time-step. If ownership is enabled, the borrow method is used to redistribute owner shares of this inflow, so that owners with water surplus to their requirements lend water to those that have a deficit. The steps are as follows:

For each future time-step ft = t+minOT to t+maxOT for which an order exists at this node

1. The forecast inflow is determined for the time-step ft for each owner o:

Gain(o) = fForecastInflow(o, ft)

Change(o) = 0

2. If ownership is enabled, inflow surplus to any owners requirements is redistributed:

a. For each owner o, Surplus(o) = Gain(o) - DownstreamOrder(o,ft)

b. The borrow method is used to redistribute inflow from owners with a positive Surplus(o) to those with a negative value (insufficient flow to meet their order). This process is described in this guide’s section on . This method returns a list of changes to the distribution - Change(o).

3. For each owner o, the amount ordered is reduced by the amount of additional inflow:

UpstreamOrder(ft, o) =
DownstreamOrder(ft, o) - (Gain(o) + Change(o))

At a Loss node the order for each of the future time-steps in the order period is increased for the loss that would be incurred if the order was met. If ownership is enabled, this expected loss is distributed between owners according to rules specified by the modeller. The steps are:

For each future time-step ft = t+minOT to t+maxOT for which an order exists at this node

1. The volume of loss incurred to meet the time-step order is calculated:

Loss(ft) =
fRequiredInflow( DownstreamOrder(ft) ) - DownstreamOrder(ft)

2. If Loss(ft) > 0 (ie a loss would be incurred meeting the order), it is necessary to update orders.

If there is no ownership, the "not specified" owner is assigned the total Loss(ft). If ownership is enabled, ownership processing determines each owner’s share of the loss: Loss(o,ft). Each owner’s loss is added to each owner’s time-step order:

UpstreamOrder(o,ft) = DownsteamOrder(o,ft) + Loss(o,ft)

3. If Loss(ft) ≤ 0, the order is passed on unadjusted:

UpstreamOrder(o,ft) = DownstreamOrder(o,ft)

At a Splitter node the modeller specifies relationships that dictate the minimum and maximum effluent flow given an upstream inflow. The upstream order may be more than the sum of the orders passed from downstream. The maximum effluent relationship may dictate that more inflow is required to meet the effluent order. The minimum effluent relationship may result in more water than is required going down the effluent, leaving less than the amount required for the main channel. The steps to adjust the upstream order to meet downstream requirements on both channels are described below:

For each future time-step ft = t+minOT to t+maxOT for which an order exists at this node

1. The amount of water required upstream to meet the total downstream order upstreamRequirement will be the maximum of the total downstream order, the upstream inflow to meet the effluent order, and the upstream inflow required to meet the main order:

effluentInflowReq = fRequiredInflowForEff(EffluentOrder(ft))

mainInflowReq = fRequiredInflowForMain(MainOrder(ft))

TotalOrder = EffluentOrder + MainOrder

upstreamRequired = Max(effluentInflowReq, mainInflowReq, TotalOrder)

2. If the total order downstream of the splitter node is less than the upstream inflow required to supply it (loss > 0), the order passed upstream is increased. To do this, the processing resembles a loss node. The outlet order with the largest upstream inflow requirement is increased to account for the expected flow that will be "lost" in meeting the remaining requirement on the other outlet.

Loss(ft) = upstreamRequired - TotalOrder

• if Loss(ft) > 0

i. The outlet order with the largest inflow requirement is chosen

If effluentInflowReq < mainInflowReq

DownstreamOrder(ft) = MainOrder(ft)

Otherwise

DownstreamOrder(ft) = EffluentOrder(ft)

ii. If ownership is enabled, ownership processing determines each owner’s share of the loss: Loss(o,ft). This is added to each owner’s time-step order:

UpstreamOrder(o,ft) = DownsteamOrder(o,ft) + Loss(o,ft)

iii. The expected loss is added to the selected downstream order for the time-step:

UpstreamOrderTotal(ft) = DownstreamOrder(ft) + Loss(ft)

• Otherwise, the order passed upstream is the sum of the order on downstream channels

UpstreamOrderTotal(ft) = TotalOrder

For each owner o

UpstreamOrder(o,ft) = MainOrder(o,ft) + EffluentOrder (o,ft)

There must be at least one regulated upstream branch for an order to exist at the Confluence node.

• If there is an unregulated upstream branch:

The "gain" from any unregulated upstream branch is forecast and used to reduce the order passed upstream (on the regulated upstream branch) in the same way as for an Inflow node - see the steps described under the Inflow Node subsection. This adjusted order is passed upstream on the regulated upstream branch.

• If both upstream branches are regulated, the order is processed according to the method specified at the confluence node. This method is either Constraint Based or Harmony.
• When Constraint based rules have been chosen, the modeller has specified a priority for each branch.
• When Harmony rules have been chosen, the modeller can specify a table of ratios such as the one in Table 65, or use an expression to calculate the order split.

The SplitRatio for a branch is based on the HarmonyVolume on both branches. HarmonyVolume is calculated using an expression specified by the modeller. The ratio is selected from the Harmony Table according to the HarmonyVolume values. Interpolation is used:

col = column in horizontal table for branch 1 with volume < HarmonyVolume(b1)

row = row in vertical table for branch 2 with volume < HarmonyVolume(b2)

factorB1 =
(HarmonyVolume(b1) - B1TableVolume(col)) /
(B1TableVolume(col+1) - B1TableVolume(col))

factorB2 =
(HarmonyVolume(b2) - B2TableVolume(row)) /
(B2TableVolume(row+1) - B2TableVolume(row))

Interpolation1 =
factorB1( Ratios(row,col+1) - Ratios(row,col)) + Ratios(row,col)

Interpolation2 =
factorB1(Ratios(row+1,col+1) - Ratios(row+1,col)) + Ratios(row+1,col)

SplitRatio(b1) = factorB2 (Interpolation2 - Interpolation1) + Interpolation1

SplitRatio(b2) = 1 - SplitRatio(b1)

The steps performed at a confluence node with two regulated upstream branches are:

For each future time-step ft = t+minOT to t+maxOT for which an order exists at this node:

• If the delivery time-step ft falls within the order time range for one branch b but is before the minimum order time for the other branch, the order is only passed up branch b (as it is now too late to release water on branch otherB to have it arrive in time-step ft). This order is reduced by the flow expected on branch otherB in the delivery time-step:

ApproxFlow = PreviousOrder(otherB, o, ft+1) • ConstraintFactor(otherB, ft+1)

UpstreamOrder(b,o,ft) = DownstreamOrder(o,ft) - ApproxFlow

• If the delivery time-step ft is after the minimum order time for both upstream branches, orders are split between branches based on constrained flow ranges for those branches. The following steps are done for every owner o:

a. The order to be split and the total upstream constraints are determined:

RemainingOrder(o) = DownstreamOrder(o,ft)

MinTotal(o) =∑regulated branch bUpstreamMinConstraint(b,o,ft)

MaxTotal(o) =∑regulated branch bUpstreamMaxConstraint(b,o,ft)

b. If DownstreamOrder(o,ft) < MinTotal(o), it is split according to the branch’s share of the total upstream minimum constraint. Once this is done, the order split is complete.

For each regulated branch b:

Order(b,o,ft) =
DownstreamOrder(o,ft) • UpstreamMinConstraint(b,o,ft) / MinTotal(o)

RemainingOrder(o) =0

c. If RemainingOrder(o) ≥ MinTotal(o), both branches are initially assigned an order to fulfil the requirement of their minimum constraint.

For each regulated branch b:

Order(b,o,ft) = UpstreamMinConstraint(b,o,ft)

RemainingOrder(o) = RemainingOrder(o) - MinTotal(o)

d. If RemainingOrder(o) > 0, this amount is assigned to the "space available" (remaining capacity) between the minimum and maximum constraint on each branch b. The modeller has specified which rules to apply when splitting the order:

For each (regulated) branch b, in order of priority if using constraint based rules

SpaceAvailable =
UpstreamMaxConstraint(b,o,ft) - UpstreamMinConstraint(b,o,ft)

• If the modeller specified Constraint Based rules, the branch is assigned the remaining order up to its maximum capacity constraint:

Assigned = Min(SpaceAvailable, RemainingOrder(o))

• Otherwise, the modeller specified Harmony rules. The remaining order is split using the harmony split ratio, and the branch is assigned its share of the volume to its maximum capacity constraint:

Assigned = Min(DownstreamOrder(o,ft) • SplitRatio(b), SpaceAvailable)

Order(b,o,ft) = Order(b,o,ft) + Assigned

RemainingOrder(o) = RemainingOrder(o) - Assigned

e. If there is any remaining order volume to pass upstream (RemainingOrder(o) > 0) this amount is split using the type of rules specified:

Constraint Based rules: The order must have exceeded the total maximum capacity constraint. The remaining amount is split according to each branch’s share of this constraint:

For each (regulated) branch b

Order(b,o,ft) =
Order(b,o,ft) +
RemainingOrder(o) •
UpstreamMaxConstraint(b,o,ft) /
MaxTotal (o)

Harmony rules:

i. There may still be capacity available on one upstream branch. This is filled first:

For each (regulated) branch b

If Order(b,o,ft) < UpstreamMaxConstraint(b,o,ft)

Assigned = Min(RemainingOrder(o),

UpstreamMaxConstraint(b,o,ft) - Order(b,o,ft))

Order(b,o,ft) = Order(b,o,ft) + Assigned

RemainingOrder(o) = RemainingOrder(o) - Assigned

ii The order remaining past the total maximum capacity constraint is split between branches using the harmony split ratio:

For each (regulated) branch b

Order(b,o,ft) = Order(b,o,ft) + RemainingOrder(o) • SplitRatio(b)

f The branch’s share of the order to be delivered to this node in future time-step ft is only passed upstream if the time has come to do so, ie if ft is before/at the latest time-step in which water can be delivered from an upstream source on the branch:

For each (regulated) branch b

If ft ≤ t+maxOrderTime(b)

UpstreamOrder(b,o,ft) = Order(b,o,ft)

Otherwise the order for delivery in time-step ft will be passed upstream later on.

The rules based ordering system forecasts the volume of water in storage per owner at the end of the order period so that it can place orders to keep the storage volume within its optimal operating range (defined by the modeller). The order placed is one estimated as required to meet the maximum target operating level . Releases for the order period on each outlet path are also created based on the downstream order in readiness for the flow phase.

1. The storage node’s water level (and associated surface area) over the order period is estimated to be at the top of the storage’s target operating range, or the current level if this is higher:

EstLevel = Max(CurrentLevel, MaxOperatingTargetLevel)

EstSurfaceArea = Min(FullSupplySurfaceArea, fSurfaceArea(EstLevel))

2. The required volume of water to meet orders is compartmentalised into:

a. The amount that can be stored here (ie for owners with storage capacity)

OrderHere =
∑ft=t to MinOT ∑o1=owners with capacity DownstreamOrder(o1,ft)

b. The amount stored upstream (ie for owners without storage capacity here)

OrderUpstream =
∑ft=t to MinOT ∑o2=owners without capacity DownstreamOrder(o2,ft)

3. Each owner’s storage is estimated at the maximum order time, assuming that no orders are passed upstream to fulfil future orders. For each owner o:

a. Net evaporation and seepage is estimated using the estimated water level and associated surface area:

EstimatedNetEvaporation(o) =
∑ft=t to MaxOT ShareNetEvap(o) • fEstNetEvapRate(ft) • EstSurfaceArea • dt

EstimatedSeepage(o) =
∑ft=t to MaxOT ShareSeepage(o) • fInfiltrationRate(TargetLevel) • dt

b. The estimation of inflow and release volume is based on orders:

EstimatedInflow(o) = ∑ft=t to MinOT DownstreamOrder(o,ft)

If owner o has storage capacity share

EstimatedInflow(o) =
EstimatedInflow(o) • (fPredictedInflow(t) - OrderUpstream) / OrderHere

EstimatedRelease(o) =
∑ft=t to MaxOT DownstreamOrder(o,ft)

c. The storage at the maximum order time if future orders are not passed upstream is estimated as:

EstimatedStorage(o) =
Storage(o,t) + PredictedInflow(o) - EstimatedRelease(o) -
EstimatedNetEvaporation(o) - EstimatedSeepage(o) - EstimatedSpill(o)

4. A list of releases due in the current time-step is created for every outlet path p. This list is used in the time-step flow phase:

ReleaseDue(p,o) = DownstreamOrder(p,o,t)

ReleaseDue(p) = ∑owner o ReleaseDue(p,o)

5. If there are downstream orders for any time-step over the order period, orders are created or adjusted over the ordering period to keep the storage volume up to its maximum operating target level:

TargetVolume = Min(fVolume(MaxOperatingTargetLevel), FullSupplyVolume)

For each owner o, TargetVolume(o) = TargetVolume • ShareCapacity(o)

For each of the future time-steps ft between t+minOT and t+maxOT and each owner o

If EstimatedStorage(o) < TargetVolume(o)

TotalFutureOrder(o) = ∑ft=MinOT+1 to MaxOT DownstreamOrder(o,ft)

If TotalFutureOrder(o) > 0

Shortfall (o) =
Max(0,(TargetVolume(o) - EstimatedStorage(o)) •
DownstreamOrder(o,ft) /
TotalFutureOrder(o)

Otherwise

Shortfall (o) =
Max(0,(TargetVolume(o) - EstimatedStorage(o)) /
(MaxOT - MinOT + 1)

Future version of Source: Each owner’s order adjustment Shortfall(o) will be scaled back to their share of the volume required for the overall storage target. If there is no internal spilling and only individual owner’s shortfalls are considered, owners may end up ordering more than required and cause the storage to spill.

TotalShortfall = Max(0, (TargetVolume - ∑oEstimatedStorage(o)))

SumOwnerShortfall = ∑o Max(0, (TargetVolume(o) - EstimatedStorage(o)))

Shortfall(o) = Shortfall(o) • TotalShortfall / SumOwnerShortfall

UpstreamOrder(o,ft) = DownstreamOrder(o,ft) + Shortfall(o)

Flow may be set to observed values at a Gauge node. When a RiverOperator scenario is run, orders are adjusted for the "unaccounted difference" between modelled and observed flow. Neither the modelled or observed flow is not known for future time-steps (covered by the order period), so a forecast model is used to estimate unaccounted difference based on past observations.

For each future time-step ft = t+minOT to t+maxOT for which an order exists at this node

1. The unaccounted difference for time-step ft is estimated using the specified forecast model:

ForecastUD(ft) = fForecastUD (t,ft)

2. If ownership is enabled, the forecast unaccounted difference is shared between owners according to "Other lateral flux" sharing rules defined for the ownership system for the Gauge node. Flow surplus to any owners requirements is then redistributed. See for more information.

a. ForecastUD(o,ft) = Share(o) • ForecastUD(ft)

b. For each owner o

Surplus(o) = ForecastUD(o,ft) - DownstreamOrder(o,ft)

c. The borrow method is used to redistribute inflow from owners with a positive Surplus(o) to those with a negative value (insufficient flow to meet their order). This process is described in this guide’s section on . This method returns a list of changes to the distribution: Change(o).

d. The unaccounted difference is adjusted for the borrow between owners:

ForecastUD(o,ft) = ForecastUD(o,ft) + Change(o))

3. The order volume is reduced by the unaccounted difference for each owner o:

UpstreamOrder(o,ft) = Max(0, DownstreamOrder(o,ft) - ForecastUD(o,ft))

At this type of node, the order is increased for any shortfall in meeting the minimum flow requirement. When ownership is enabled, the each owner’s share of the adjustment, Share(o), is the same as their share of the minimum flow requirement - specified by the modeller at the node. See for more information.

Where an expression is used to define minimum flow requirement, the current time-step’s evaluation is used to adjust constraints for all of the future time-steps in the order period.

For each of the future time-steps ft between t+minOT and t+maxOT:

MinFlowTotal = fMinFlowReq (t)

DownstreamOrderTotal = ∑owner o DownstreamOrder(o,ft)

If DownstreamOrderTotal < MinFlowTotal

Shortfall = MinFlowTotal - DownstreamOrderTotal

For each owner o

UpstreamOrder(o,ft) = DownstreamOrder(o,ft) + Share(o) • Shortfall

Otherwise

For each owner o

UpstreamOrder(o,ft) = DownstreamOrder(o,ft)

At this node, the total order is capped to the total maximum order constraint. If ownership is enabled, owners with surplus capacity may lend to those with a deficit. This borrowing is done at each constraint level, as owner shares may change at each level.

Where an expression is used to define maximum order constraint, the current time-step’s evaluation is used to adjust constraints for all of the future time-steps in the order period.

The maximum order node steps are:

For each of the future time-steps ft between t+minOT and t+maxOT:

1. If ownership is enabled, constraint volumes at each level are checked to ensure they are non-negative, and increase from the previous level. An error is logged if this is not the case. This check is necessary during the scenario run as expressions can be used to determine level volumes in each time-step.

2. The maximum order that can be passed upstream is initially zero for each owner:

MaxOrder(o) = 0

3. If ownership is enabled, the order is processed at each constraint level defined by the modeller to determine the size of order that can be passed upstream Order(o).

For each constraint level:

a. The remaining order that can be met at this level LevelOrder(o) and the level’s surplus/deficit capacity Surplus(o) is determined for each owner o:

RemainingOrder(o) = DownstreamOrder(o,ft) - MaxOrder(o)

LevelConstraint(o) = Share(o,level) • (fMaxOrder(level) - fMaxOrder(level-1))

LevelOrder(o) = Min(Constraint(o), RemainingOrder(o))

Surplus(o) = Constraint(o) - RemainingOrder(o)

b. The borrow method is used to redistribute unused capacity from owners with a positive Surplus(o) to those with a negative value. This process is described in this guide’s section on . This method returns a list of changes to the distribution: Change(o).

c. The level’s maximum order LevelOrder(o) and the adjustment Change(o) are added to the maximum order to be passed upstream for each owner o:

MaxOrder(o) = MaxOrder(o) + LevelOrder(o) + Max(0,Change(o))

Note: fMaxOrder(level 0) = 0

4. The upstream order for each owner o is the downstream order, constrained by their total capacity share over all constraint levels:

UpstreamOrder(o,ft) = min(DownstreamOrder(o,ft), Order(o))

Each downstream owner’s order for every time-step in the order period is transferred to upstream owners according to the proportions specified by the modeller:

For each of the future time-steps ft between t+minOT and t+maxOT

For each upstream owner uo

UpstreamOrder(uo,ft) = ∑do transferProportion(uo, do) • DownstreamOrder(do, ft)

Before the time-step flow phase, additional releases for off-allocation are determined at each storage node. This is described under this guide’s entry for .

Releases are created on every outlet path at each Storage node during the time-step flow phase. The modeller may have specified that an outlet path’s release be set to a gauged value. If this is not the case, the modelled release is used, which is the combination of the regulated order due in the time-step (ReleaseDue(p)) and the off-allocation volume, constrained by outlet path capacity. The volume released on the outlet path will always be at least its minimum release (spill) for the storage volume.

At the end of the time-step flow phase processing for each model element on a regulated supply path, the following steps are performed by the rules based ordering system:

Steps at each model element at the end of the flow phase

1. Order, off-allocation request and constraint lists are reset (emptied).

2. Owner constraint factor lists are processed and recorded. These lists have an entry for each time-step between the current one and the element’s minimum order time. Note that constraint factor lists are not reset each time-step.

a. At some elements, the latest entry in each owner’s constraint factor list is calculated & set:

• Storage node - The constraint factor is set to the fraction of the owner’s order due that is released on the outlet path:

ConstraintFactor(p,o,t) = Min( 1, Release(p,o,t)/PreviousOrder(o,t) )

• Splitter node: The constraint factor at each outlet (main or effluent) is set to the fraction of orders due at the outlet channel that is delivered as flow from that channel. This is the same for every owner.

ConstraintFactor(p,o,t) =
Min( 1, DownstreamFlowTotal(p,t)/PreviousOrderTotal(p,t))

• Maximum Flow Constraint Node, Transfer of Ownership Node or Links connected to a Storage node outlet : At these model elements, each owner’s share of the constraint factor for the latest time-step is based on their minimum flow share on the downstream path:

ConstraintFactor(o,t) starts at 1

For each element de on the path downstream:

ConstraintFactor(o,t) =
Min(
ConstraintFactor(o,t),
DownstreamFlowTotal (t) • Share(de,o,t)/PreviousOrder(o,t)
)

b. The constraint factor list is recorded.

c. If the element is a Confluence node with both upstream paths regulated, the lists from the upstream element on each path are merged. This is done for each owner as follows:

For each time-step ft from now up to the latest minimum order time of both paths/branches:

TotalOrder = PreviousOrderTotal(b1,ft) + PreviousOrderTotal(b2,ft)

Factor1, Factor2 = 0

If there is an entry in branch b1 for time-step ft:

Factor1 = ConstraintFactor(b1,o,ft) • PreviousOrderTotal(b1,ft)/TotalOrder

If there is an entry in branch b1 for time-step ft:

Factor2 = ConstraintFactor(b2,o,ft) • PreviousOrderTotal(b2,ft)/TotalOrder

ConstraintFactor(o,ft) = Factor1 + Factor2

d. The constraint factor list passed to the next model element downstream. The upstream element’s list overwrites the entries for matching future time-steps in the downstream element’s list, as it now contains newer estimates for those time-steps. The oldest entry in the downstream list now refers to the ordered flow due to move downstream of the element in the previous time-step. This entry is deleted as it is no longer needed for constraint processing. See the example in Figure 72.

The input parameters at each node and link used specifically by the rules based ordering system are described below.

The Demand models selected at a Water user node generate demand that translates to orders processed by the rules based ordering system. Distribution parameters determine how the demand translates to an ordered volume at each Supply Point node.

The Over Order Factor is used by the rules based ordering system to increase the water user’s order that enters the network at the supply point.

The Forecast parameters are used by the rules based ordering system to forecast inflow in future time-steps.

The rules based ordering system uses the Ordering parameters for routed links when processing orders. These include:

• Fluxes in Ordering: Dictate which lateral fluxes to adjust orders for (Groundwater, Time Series, Loss/Gain, Net Evaporation). Orders will be increased for loss, and decreased for gain from the selected fluxes over the time the ordered water takes to pass through the link.
• Net Evaporation parameters: These are used to generate a forecast of rainfall plus evaporation. Either a monthly pattern or an expression can be specified.
• Groundwater flux parameters: These are used to generate a forecast for the loss or gain of link flow to groundwater. The relationship between level (depth) and flow (loss/gain to groundwater) can be specified, or alternatively a groundwater model may be selected.

The Confluence node’s Ordering parameters dictate how orders are processed by the rules based ordering system:

• Regulated Ordering Methodology: Type of rules that govern the way orders are split at the Confluence node. This is either "Constraint Based" or "Harmony Based".
• Link Table: This has one row for each of the Confluence node’s inlet links. See Table 66 for a description of parameters in this table.
• Link forecast model parameters: These are only used when one link is regulated and the other link is not. The model is used to generate a forecast of inflow from the unregulated link - which can be used to reduce orders passed up the regulated link.
• Harmony parameters: These are only used when the "Harmony Based" Regulated Ordering Methodology is chosen. See Table 67 for a list.

The following input parameters are used exclusively by the rules based ordering system to estimate storage volume at the end of the storage node’s future order period:

• Forecast Inflow: Expression to calculate an estimate of forecast inflow from upstream (the expression is executed in the part of the time-step specified by the modeller).
• Forecast Evaporation Pattern: Monthly time series of net evaporation (rainfall plus evaporation).

Other parameters that must be set up correctly in order for rules based ordering to function properly include:

• Storage Dimensions: The Level/Volume/Surface Area table
• Storage Details: Maximum Operating Level
• Seepage: Level/Seepage table
• Outlets: Level/Discharge table

The Requirement Properties selected at this node determine the minimum constraint value for the node’s location in the scenario network.

If ownership is not enabled, this node’s Constraint Properties dictate the maximum constraint value for each time-step at the node’s location.

When ownership is enabled, this information used by rules based ordering is entered in the Ownership properties. In this case information is entered in a table, with a row representing a "Constraint Level". The columns configured are:

• Flow Constraint expression. This returns a volume that should increase with each constraint level (table row). The volume returned by the expression for the last row of the table is the maximum order constraint volume.
• Owner% columns: Each owner’s share of the volume between this row and the next row’s Flow Constraint volume.
• Distribution system: Rules used to redistribute each owner’s excess capacity (unused constraint volume) to other owners with a deficit. See this guide’s entry on systems for more information.

Figure 71 illustrates the concept of constraint levels up to the maximum order constraint. Each owner’s coloured area under the whole curve represents their maximum constraint volume. At the each point where a level’s section of the curve ends, owner shares of the volume underneath change.

This node’s Ordering parameters dictate how the rules based ordering system processes orders at its location. These parameters consist of a table, with a row for each downstream owner, and a column for each upstream owner. The percentage or proportion in the table cell is the fraction of the downstream owner’s order to transfer to the upstream owner.

Output data is viewed using the Recording Manager. The recorded attribute values (results) are reported for each time-step of the model run. Results relevant to rules based order processing are described in this section. The items shown are reported at every node and link for which recording of rules based ordering information is selected.

Attributes for Ordering Phase (Regulated) are summarised in Table 68.

These attributes are only reported at Supply Point nodes. They are used in the same way as the corresponding attributes for the Ordering Phase (Regulated) interface, except they refer to orders placed by the water user at the Supply Point, rather than the total order volume at the node.

These attributes are described in this guide’s entry for flow sharing.

These attributes are described in this guide’s entry for flow sharing.

Constraint Phase attributes are summarised in Table 69.

This functionality is yet to be documented. If you would like assistance, please call 1300-5-WATER (1300-592-837).

This functionality is yet to be documented. If you would like assistance, please call 1300-5-WATER (1300-592-837).