Note: This is documentation for version 4.3 of Source. For a different version of Source, select the relevant space by using the Spaces menu in the toolbar above

Rules-based ordering

Owned by asatheesh (Unlicensed)
Last updated: 13 Oct 2023 by TeamcityVersion comment
3 min read

Introduction

There are three key components of rules-based ordering:

  • Calculation of order time within a network - order time is calculated in the initialisation phase of a Source project and is required by the ordering and off-allocation systems to determine how many time-steps into the future water orders need to be processed for at each network component; and
  • The way orders in the network are processed at each node/model component - Orders are processed in the constraint and order phases. During the ordering phase, water orders and off-allocation requests are accumulated from downstream to upstream and consider the average travel time of water in the regulated river system downstream of a reservoir.
  • Prioritisation of orders from nodes to determine which orders will be met first in the system in the event of any shortfall

In the ordering phase, rules based ordering system calculates the total volume of order required at each node and link to meet downstream demand. Orders are received at a node from the downstream node, is adjusted as required, then 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 order.

For example, assume an order reaching a loss node is 100ML; due to its characteristics, it loses 20ML. To make up for this reduction, the loss node must now order 120ML, which is the new order that travels upstream. This section deals with processing of orders when ownership has not been enabled (ie. a system containing a single, default owner).

Ordering is configured at the confluence and storage nodes, as well as at a storage routing link.

Confluence node

Refer to the /wiki/spaces/SD43/pages/53543657 for configuring ordering at this node. Orders are passed onto the branch depending on the following:

  • If orders are directed to a particular storage along a branch, the confluence node will pass them up that branch; or
  • If orders can be supplied along multiple paths or by multiple storages, orders can be distributed using either the Harmony-based or Constraint-based method.

Storage node

Source forecasts the volume of water in storage at the end of the order period so that it can place orders to keep the storage volume within its optimal operating range. Refer to Ordering at storages when configuring ordering at a storage node. 

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. You can choose which of these lateral fluxes the ordering system takes into account by enabling the relevant checkbox shown in the node’s feature editor (Figure 1). The data for each of the fluxes is taken from its corresponding item in the hierarchical list. For example, if you enable Use Loss/Gain, Source uses the table specified in Loss/Gain. If you choose Groundwater as one of the fluxes, you must specify a time series for it, which can be imported.

The order coming into the routed link is adjusted to cater for the lateral fluxes over each time-step that the ordered flow spends in the link.

Figure 1. Link (Ordering)

Note: Changes in link storage volume are not forecasted over the order period, as it does in the storage node. So, 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.