During each time-step, Source operates in two phases: the ordering phase and the flow distribution phase. The ordering phase accumulates orders and determines the targets for release and distribution of regulated water. The flow distribution phase releases water, routes flows and distributes water through the river network.
During the ordering phase, the release of water to satisfy orders can be computed in one of two ways:
- statically, using a set of predefined rules, or
- dynamically, using a Network Linear Program (NetLP) to find an optimal solution.
Source refers to the latter as Optimised Ordering.
Why use Optimised Ordering?
It is often desirable to operate multiple storages in such a way as to maintain pre-determined relationships between them. Scenarios include:
- storages in series on the same branch of a river system;
- storages located in different branches of a river system and operated in parallel; or
- combinations of both of the above.
It is also possible to have multiple paths for the transmission of water, such as occur in the presence of anabranches.
Determining optimum release and travel patterns is complex and the network linear program employed by Optimised Ordering can assist operators in making decisions to run a river system efficiently.
Scale
One or more iterations per time-step.
Principal developer
RELAX IV was developed by Dimitri Bertsekas, and some bindings to RELAX IV were developed by George Kuczera. PPRN was developed by Jordi Castro. The implementation of these in Source is specific to eWater CRC.
Version
Source version 3.0.2
Availability/conditions
Version 1 of Source will not include performance tuning for runtimes, full side constraint capability, complex ownership interactions, routing, or partial optimisation.
Theory
The standard form of a linear programming function is as follows:
| Equation 1 |
|---|
subject to the constraints:
| Equation 2 |
|---|
where:
x represents the vector of variables to be determined
c is an n-vector of costs or penalties
d is an m-vector of known nodal inflow or outlow volumes (coefficients)
l and u are lower and upper bounds, respectively, on x
A is a (m,n) node-incidence matrix of whose (i,j)th element is defined:
Equation 3 | if arcjis directed towards nodei | |
|---|---|---|
| otherwise | ||
| if arcjis directed away from nodei |
The constraint AX=d ensures that mass balance is achieved at every node in the network. This is always the linear program solver’s highest priority.
Optimisation (Linear programming) algorithms
Source currently supports the following optimisation algorithms:
- PPRN with side constraints
- PPRN without side constraints
- PPRN with network duplication
- RELAX IV
- RELAX IV with network duplication
PPRN uses real numbers and is a true linear programming algorithm. RELAX IV uses integers and is more properly described as an integer programming algorithm.
Side constraints
Side constraints are implemented, automatically, by translating between requirements set in nodes or links in the Source schematic, to constraints imposed on the arc-node model provided to the solver.
Side constraints can enforce requirements and can also promote more rapid convergence by eliminating options.
Only PPRN supports side constraints.
Assumptions
All linear programs assume perfect data. To the extent that the data provided to the solver by Source does not satisfy this assumption, the solutions found by the solver may be sub-optimal.
Source integration
The details of the operation of the network linear program are largely hidden from the user. Source performs the translation between the per-scenario Node-Link network visible in the Schematic Editor and the arc-node network which is created for each time-step for use by the network linear program. Source also manages the numbers of iterations which are required at each time-step. Figure 1 summarises how Source interacts with the network linear program.
Notes:
Inflow forecasting: In general, inflow forecasting for NetLP works in the same way as it does for Rules Based Ordering (see the Rules-Based Ordering - SRG entry for details). A point to note is that NetLP models are often monthly. In monthly models, the basis for inflow forecasts at inflow nodes and unregulated confluences often differs from that for shorter time step models such as daily models. In a daily model the forecast for each time step's inflow is typically based on a recession from the previous time step's inflow. In a monthly model the forecast inflow is typically the actual inflow for the time step. To achieve this the Trend Forecast Model is configured with a (recession) rate of 0.0, and there is no forecasting from the current time step.
Travel times: In the order phase for NetLP, travel time is modelled by making a replica of the appropriate parts of the network for each full time step's travel time (up to the maximum network travel time) and aggregating into a single network. The aggregated network is then solved, giving a solution as far forward as the maximum network travel time. This allows optimised orders to be determined the appropriate time in advance (note that NetLP models are often monthly and, as travel times used for ordering are rarely, if ever, longer than this, for monthly models only the current time step is considered). The orders are then passed to the flow phase where processing occurs as per rules based ordering (see the Rules-Based Ordering - SRG entry for more information).
...