Rules-Based Ordering - SRG

If the Supply Point node is set to 'Extract Water' then the minimum and maximum constraints will be set to the upstream minimum and maximum constraints minus the Supply Points Demand to represent the water expected to be extracted at this point. Ownership of the extracted water is dictated by the modellers distribution settings at the connected water user and will be used accordingly on the constraints.

If the Supply Point node does not extract water no alterations to the upstream constraints will be made.

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 SRG.

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 1 for an illustration of this concept.

Open

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 - SRG.

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 Transfer ownership node - SRG for more information.

Ordering priority functionality has been created to try and develop a simple and effective system that allows users in Source to specify how shortfalls are prioritised between different demands in Source. It aids in providing information on how water is supplied to users along regulated river reaches between regulating structures. See ordering with priorities for details.

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); and

• 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 2 under Propagation of orders and constraints.

Open

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 functions 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 - SRG and Water user node SRG.

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 2. 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.