Page Comparison

In each time-step, the NetLP needs to solve an arc-node network to determine a set of releases for a given set of orders and constraints.

Where capacities and demands vary according to predicted flows, the NetLP needs to arrive at a solution iteratively. An optimised solution is considered to have been found when the differences between two successive iterations fall within specified limits.

The optimised solution provides the flow distribution phase with order information for that time-step, including the best way to supply the orders and to move water through the system.

The flows observed during the flow distribution phase will generally be greater than or equal to the ordered flows unless, for example, losses were greater than estimated, or actual inflows less than those originally forecast.

Arc-node translation

This section contains a selection of arc-node models which are typical of those generated by Source. The information presented here can not possibly cover all possible permutations and combinations. As a result, it should be considered broadly informative without being necessarily either comprehensive or authoritative.

Each arc connecting two nodes within a model carries an annotation of the form shown in Figure 2:

Arcs are uni-directional with arrow-heads indicating the direction of flow. In addition:

• An arc with a zero cost represents neither an incentive nor a disincentive.
• An arc with a positive cost has a cost disincentive. The greater the magnitude of the positive number, the greater the disincentive for water to flow along that arc.
• An arc with a negative cost represents a cost incentive. The greater the magnitude of the negative number, the greater the incentive for water to flow along that arc.

The default costs for arcs are predefined within Source.

Ownership is modelled by constructing replicas of the system for each owner, containing only those features to which the owner has access.

Replicas are also used to model transmission delays in the system.

Splitter

A splitter (regulated or natural system) forces the proportion of water allocated to the effluent to flow down that path, with the balance travelling down the main channel. The proportion of water allocated to the effluent (or regulated side) is set in the Splitter (or Regulated Splitter) node using a piecewise linear editor. See Figure 3.

A minimum flow requirement is implemented by a two-arc construct. The requirement has a high incentive arc limited to the value of the constraint. Any water beyond the minimum will flow via the excess path which has a zero cost. The constraint is set on the corresponding Minimum Flow Requirement node in the Source schematic.

Environmental  Flow Requirement

An environmental flow requirement is implemented by a two-arc construct. The environmental flow requirement has a high incentive arc limited to a value determined by Environmental Flow modelling. Any water beyond the minimum will flow via the excess path which has a zero cost.

When an Environmental Flow node is present in the network, the Net LP solver engages a special 2-phase solution. A solution of for the network is determined in the first phase, the incentive arc set to 0 to determine the expected flow. Then the Environmental Flow modelling takes place using these expected flows as an input, and determines an enivronmental environmental demant. The second phase then takes place, using the environmental demand to for the high incentive arc. 

Confluence

The confluence is implemented as a single node construct that is connected to the upstream and downstream constructs as the network is built. See Figure 4.

A maximum order constraint is implemented by a two-arc construct. The constraint has a zero cost arc limited to the value of the constraint. Any water beyond the maximum may flow via the hidden path which has a very high disincentive. In effect, any water over and above the constraint equates to a flood condition. The constraint is set on the corresponding Maximum Order Constraint node in the Source schematic. See Figure 5.

A loss forces the proportion of water lost from the system to flow to the balance node over a high-incentive arc. The proportion of loss is set on the corresponding Loss node in the Source schematic using a piecewise linear editor. See Figure 6.

A demand draws an amount of water via an extraction point node. Demands are created using the various kinds of Water User node within the Source schematic. If there is sufficient water in the system to satisfy a given demand, the volume required flows to the extraction point node with any excess returned to the balance node. If there is insufficient water in the system to satisfy demand, any shortfall may be satisfied via the shortfall arcs running between the balance node and the extraction point node, according to the extraction point node’s priority, relative to other extraction point nodes in the system. See Figure 7.

Within a storage, evaporation is satisfied first. This is implemented as a very-high-incentive arc to the balance node. There is an incentive to retain water in storage. This is achieved via the storage carry-over arcs which convey most of the stored water in a time-step to the balance node, where it carries-over to the next time-step. The number, priorities and volumes of the carry-over arcs (break-points) for a given storage can be set relative to other storages in the system to implement various release and operational objectives. See Figures 8 and 9.

All data is supplied to the solver automatically by Source. There are no separate or externally-configurable data sources.

Solvers use arc-node networks as their inputs. Source derives arc-node networks automatically for each time-step from the node-link network in the Schematic Editor.

Source provides information from the previous flow phase at the start of each time-step to initialise the NetLP, such as storage volume in reaches and reservoirs, water use requirements, forecast inflows and current ownership of water in storages and reaches.

Source uses real numbers internally. When RELAX IV is chosen as the optimisation algorithm, all real numbers are scaled on entry to, and on return from, RELAX IV, to minimise loss of precision.

Output data

The solver provides the flow distribution phase with information on how to distribute flow at regulators, constraints on demands and ownership of orders at each storage and routing reach.

There may be differences between the solution found by the solver ("as predicted") and flows as modelled during the flow distribution phase ("as released"). The flow distribution phase resolves these differences by considering the ordering phase as having provided a minimum target to aim for.

Iteration control

The NetLP iterates to find the optimal solution. Usually, the NetLP will find a solution quickly. Under some circumstances, the NetLP will not converge upon a solution quickly and will keep iterating. The user can limit the number of iterations to force acceptance of a (possibly) sub-optimal solution. The user can also set tolerance thresholds to define per-arc convergence criteria.

Cost functions

Cost functions determine both the relative importance of keeping water in a storage, and the relative importance of water in one storage compared with water in another storage. By default:

Each storage has a single cost function comprising four break-points associated with 25% of the storage’s capacity.

All storages are considered equal, regardless of differences in capacity.

Cost functions have a granularity of one month (ie. while a given cost function can be applied to a storage for zero or more months, only one cost function can be applied to a storage for any given month).

Cost functions are designed using the Source user interface.

Shortfalls

A shortfall occurs when there is insufficient water in a system to satisfy all demands. Source provides a mechanism for instructing the solver how to prioritise competing demands.

Bibliography

Bertsekas, D.P. & Tseng, P. 1994, RELAX-IV: A faster version of the RELAX code for solving minimum cost flow problems, Technical Report P-2276, Massachusetts Institute of Technology, http://www.mit.edu/dimitrib/www/noc.htm [retrieved 11 March 2010].

Bertsekas, D.P. 1991, Linear network optimization: algorithms and codes, The MIT Press.

Castro, J. 1994, PPRN 1.0, User’s Guide, Statistics & Operations Research Dept, UPC, ftp://ftp-eio.upc.es/pub/onl/reports/dr1994-06.pdf [retrieved 11 March 2010].

Castro, J. & Nabona, N. 1996, "An implementation of linear and nonlinear multicommodity network flows", European Journal of Operational Research, vol. 92, no. 1, pp. 37-53.

Chen, J., Kim, S., Penton, D., Kinsman D. and Welsh, W. 2011, "Visualising Equivalent System Networks in the NetLP Optimisation of Water Distribution Systems", 19th International Congress on Modelling and Simulation, Perth, Australia, 12-16 December 2011, pp. 2303-2309.

Delgado, P., Kelley, P. Murray, N. & Satheesh, A., Source User Guide, eWater Cooperative Research Centre, Canberra, Australia.

Gilmore, R. 2009, River Systems Project : Source Rivers : Optimised Multiple Supply Modelling : Specification : Version 1.0, eWater Cooperative Research Centre, Canberra, Australia.

Gilmore, R.L., Kuczera, G., Penton, D. & Podger, G. 2009, "Improving the efficiency of delivering water in Australian river systems: modelling multiple paths", 18th World IMACS / MODSIM Congress, Cairns, Australia 13-17 July 2009, pp. 225-231.

Gilmore, R. 2008, Multiple Supply Paths Test Case: Lachlan River System, NSW, eWater Cooperative Research Centre, Australia.

Ilich, N. 2008, "Shortcomings of linear programming in optimizing river basin allocation", Water Resources Research, vol. 44, no. 2, pp. W02426.

Ilich, N. 2009, Limitations of etwork Flow Algorithms in River Basin Modeling, Journal of Water Resources Planning and Management, vol. 135, no.48, pp.1-8

Israel, M.S. & Lund,J.R.1999, Priority preserving unit penalties in network flow modeling, J. Water Resources Planning Manag., vol.125,no.4, pp. 205-214 Kuczera, G. 2008, Lag network diagrams (personal files), University of Newcastle, Callaghan, NSW.

Kuczera, G. 1989. "Fast multireservoir multiperiod linear programming models." Water Resour. Res., vol.25, no.2, pp.169-176

Kuczera, G. 1992, "Water supply headworks simulation using network linear programming", Advances in Engineering Software, vol. 14, no. 1, pp. 55-60.

Kuczera, G. & Diment, G. 1988, General water-supply system simulation model-WASP. J Water Resour Plan Manage-ASCE, vol.114,no.4, pp.365-382

Penton, D. 2009, Multiple Supply Path : Design Document : Optimisation, eWater Cooperative Research Centre, Canberra, Australia.

Penton, D. 2009, The NetLP Ordering Component : Guide and Introduction, eWater Cooperative Research Centre, Canberra, Australia.

Perera, B.J.C. & James, B. 2003, "A generalised water supply simulation computer software package-REALM", Hydrology Journal, Institute of Engineers, India, vol. 26, no. 1-2, pp. 67-83.