Automated simplification of water
networks models
Internship report - Master 2 CCI
Kamelia BOUSSAFEUR-LAMOUDI
August 2013
Directed by:
Dr. Jean-Louis Bergerand
Dr. Fabienne Carrier
- Schneider-Electric/Analytics for Solutions
- Université Joseph Fourier / UFR-IM2 AG
Abstract
This report presents the work realized at Schneider Electric during my internship of Master’s degree in Consolidation Training in Computer Science at the Université Joseph Fourier.
This internship covers two domains, hydraulics and information technology. The objective is to create a tool for simplification of water distribution networks models. The company profile, the project handled and the work realized are described later on through this
document.
Acknowledgments
First of all, I would like to thank my main supervisor Jean-Louis Bergerand for his help
and guidance. I also thank Véronique Boutin who welcomed me and introduced the
project. I am grateful to Alfredo Samperio who ensured that I had all necessary tools to
do my work. A special thank to my colleague and husband Yacine Lamoudi who helped
me format this document. Finally, I thank my second supervisor Fabienne Carrier for her
comments on the document.
Contents
Introduction
4
1
.
.
.
.
.
.
.
.
5
5
5
5
6
8
8
8
8
2
Water networks
2.1 Water network modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Water network simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Water network simplification . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
15
15
3
Water network simplification tool
3.1 Requirements and constraints
3.2 Description of the input file .
3.3 Class diagram . . . . . . . . .
3.4 Implementation . . . . . . . .
3.4.1 The algorithm . . . . .
3.4.2 Parsing the input file .
3.4.3 Parsing the Excel file .
3.4.4 Simplification process
3.4.5 Preliminary results . .
20
20
20
23
25
25
25
26
26
29
Description of the project
1.1 Context of the project . . . . .
1.1.1 Schneider-Electric . . .
1.1.2 The internship . . . . .
1.1.3 Issue . . . . . . . . . .
1.2 Description of the project . . .
1.2.1 Goal . . . . . . . . . .
1.2.2 Approach . . . . . . .
1.2.3 Organization of work
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
30
Bibliography
32
Appendix A Sections of input file
33
1
List of Figures
1.1
Demand Response for water networks . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
Water network topology . . . .
Simulation of water networks .
Removal of trees simplification
Pipes in series simplification . .
Parallel pipes simplification . .
.
.
.
.
.
11
12
17
18
19
3.1
3.2
3.3
Input file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overall algorithm - Main steps . . . . . . . . . . . . . . . . . . . . . . . . . .
21
24
25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
List of Tables
1.1
Internship stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1
water network components . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
3.2
Input file sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifications of input file sections . . . . . . . . . . . . . . . . . . . . . . . .
21
22
3
Introduction
This document is my five-month internship report carried out within Schneider Electric
Company. The internship is concerned with simplification of water network models given
by Aquis which is a software used for simulating water networks behavior. This simplification aims to reduce energy optimization computing times.
Goal
The objective of this report is to describe the aims of the project, methodology followed
and work realized. It also gives perspectives for an eventual continuation of the project.
Scope
This document is the final report intended to the master jury but it is not the final report of
the project since more than a month remains to finalize the project. The final deliverables
(specifications, mock-up and partial implementation) will complete this report.
Document structure
This report consists of three parts. First, background of the project is introduced, as well
as its objectives and organization. Then, an overview on water networks and their simplifications is given. Finally, the simplification algorithm implemented is described.
4
Chapter 1
Description of the project
1.1
1.1.1
Context of the project
Schneider-Electric
Schneider Electric is a global specialist in energy management. With more than 130 000
employees in over 100 countries, Schneider Electric offers integrated solutions for many
market segments. Schneider Electric sales for 2012 reached e24 billion. Products and
services solutions cover [2]:
• Processes control and supervision
• Power supply and distribution
• Energy monitoring and control
• Utility management (lighting, ventilation, elevators, intruder alert, etc.)
• Smart electrical networks management
• Single site or multi-site production data management
• Critical power
• Offer prepayment systems that bring electricity to disadvantaged customers
1.1.2
The internship
The work presented in this report is part of the Arrowhead project. This 4-year project
started on March 1st 2013. Arrowhead project addresses energy efficiency and flexible
usage of energy through cooperative automation. More than 70 partners are involved
in the project. The contribution of Schneider Electric concerns three applications; water,
manufacturing and elevators.
5
The objective of Arrowhead project is to [1]:
• provide a technical framework adapted in terms of functions and performances;
• propose solutions for integration with legacy systems;
• implement and evaluate the cooperative automation through real experimentation;
• point out the accessible innovations thanks to new services;
• lead the way to further standardization work.
I did my internship among the team ”Analytics for solutions” which works on the
Arrowhead project. The team is responsible for developing pilots in the three domains:
water, manufacturing and elevators.
1.1.3
Issue
Energy costs related to water production and transportation represent most of operating
costs. However, some modulation in electricity consumption is possible thanks to large
volume of water storage in water networks and flexibility in managing pumping plans.
Indeed, network tanks are very useful because of varying demands for water and the various prices of consumption of electric energy [5]. The reserves stored in them are used in
periods of high demands and high energy prices. The possibility of accumulating water
in tanks and the fact that there are different prices of energy for different intervals of the
day and night make possible to manage the system in such a way that the costs of energy
used in the pumping stations are as low as possible [5].
Thus water networks offer a real opportunity for both energy efficiency and Demand
Response. Demand Response is an electric market mechanism which enables energy consumers to participate in energy markets by modifying their consumption profiles. These
modifications enable them to take advantage from low energy price periods and earn their
money back by curtailing energy load at peak times and returning it back to power grid.
One of Schneider Electric’s objectives in Arrowhead project is to turn this operation
flexibility of the water network into an energy consumption flexibility offer, to decrease
operational costs by means of new control systems and analytic decision making tools.
Schneider-Electric’s solution consists of calculating and managing Demand Response
offers on the water network by combining network hydraulic simulation, demand forecast, energy price forecast and optimization techniques. First, prevision on pumping
schedule is done. When compared to the current pumping schedule, an eventual modulation is provided. Both prevision and modulation are updated in real time. The consumer
can then propose a number of valuable services to service aggregator. The aggregator is a
service provider that creates and manages pools representing energy-buying alliance and
ensures purchase at the most competitive prices.
6
Figure 1.1: Demand Response for water networks(reference:Schneider Electric)
Hydraulic simulation uses Aquis which is a tool marketed by Schneider Electric and
the optimization is performed by Artelys which is a partner in Arrowhead project. Both
partners work on optimizing pumping schedules on an existing water network (Birkerod
town in Denmark). In the future, they aim to do optimization for any water network. As
water systems are more or less large, solving the optimization problem can become difficult. This is due to the non-linear equations that describe the behavior of the system (this
is detailed further in this document). Thus, simplification of water system models is very
useful. Actually, aggregated-simplified- models require less computation time and provide all information needed for the optimization. Hence they speed up the optimization
process and allow bigger models to be calculated [6].
7
1.2
1.2.1
Description of the project
Goal
This work is concerned with automated simplification of water network models in order
to speed up optimization computing. It concerns the topological reduction of the network.
An input file (a file with .inp extension) is generated from Aquis. This file contains data of
the network. The aim is to create a tool that modifies this file in order to obtain a less complex network. This simplified network must maintain all operating controls unchanged.
Input file of the simplified network obtained will be used to perform optimization.
1.2.2
Approach
The work consists of the following steps:
• Import network data (geometry, elements and demands) from Aquis through input
file
• Perform automated simplification
• Export results to Aquis through a new input file
• Simulate the simplified model on Aquis
• Compare simulation results of simplified model to those of the initial model
• Validate the algorithm based on these results
1.2.3
Organization of work
Table 1.1 summarizes the steps I followed during the internship to realize the different
tasks
8
]
1
2
3
4
5
6
7
8
9
Step
Duration
(days)
Introduction to project
Software installation
Procurement of licenses
Preliminary study
Bibliography
Spec. of simplification methods
Specification of .inp file
Learning how to use Aquis
Class diagram
Spec. of simplification algorithms
Implementation of algorithms
Research of innovative simplifications
Realize a mock-up for these methods
Report writing
Preparation of the presentation
Beginning
Realized
(%)
27
05/06/2013 06/11/2013
100
23
06/12/2013
07/12/2013
100
20
06/17/2013
07/12/2013
100
15
19
53
21
16
55
10
06/24/2013
06/24/2013
07/18/2013
09/02/2013
09/09/2013
06/17/2013
08/26/2013
07/18/2013
07/12/2013
09/30/2013
09/30/2013
09/30/2013
08/30/2013
09/05/2013
100
100
50
0
0
100
10
Table 1.1: Internship stages
9
End
Chapter 2
Water networks
An overview on water systems is required for a good understanding of how the created
tool works. The basic task of a water distribution system is to provide the consumers with
the needed amount of water from the source with a suitable pressure especially during
peak demand periods.
Moving water from the source to the customer requires a network of pipes, pumps, valves,
and other appurtenances [4]. Storing water to accommodate fluctuations in demand, due
to varying rates of usage or fire protection needs, requires storage facilities (tanks) [4].
Piping, storage, and the supporting infrastructure are together referred to as the ”water
distribution system” [4].
Water supply provided through the network must be with as little pipe leakage as possible
[6].So, a suitable compromise must be found by optimizing the schedules of the control
devices in the network (pumps and valves) [6].
The configuration of a water network is dictated by:
• Topography
• Street patterns
• Development of the area (number of inhabitants, types of activities...)
• Location of sources, treatment and storage works
Water networks can be either branched and/or looped (see Figure 2.1). In branched
systems, water has only one path from the source to consumers. In looped systems, there
may be several paths. This is very useful because it allows isolation of a part of the network without depriving all consumers of water.
10
(a)
(b)
Figure 2.1: Water network topology. (a) looped system, (b) branched system
Type
Element
function
Junction
Removes water from the system (demand)
Node Reservoir
Provides water to the system (source)
Tank
Stores water to meet peak demand
Pipe
Transports water from one node to another
Link
Pump
Raises hydraulic head in case of elevation differences and friction losses
Valve
Controls flow and/or pressure
Table 2.1: water network components
2.1
Water network modeling
Water network model contains all of the various components of the system, and defines
how those elements are interconnected [4].
Modeling is mainly used for: sizing of piping improvements, analysis of system pressures, storage capacity analysis, fire flow analysis, scheduling of pumping, water quality
and water age analysis, emergency response planning, vulnerability analysis, transient
analysis and leak identification [9].
Networks models are comprised of nodes, which represent features at specific locations within the system, and links, which define relationships between nodes [4]. The
table 2.1 lists the elements of network models.
Some models consider controls to be separate modeling elements, and others consider
them to be an attribute of the pipe, pump or valve being controlled [4].
11
(a)
(b)
Figure 2.2: Simulation of water networks. (a) water network in Epanet. (b) water network
in Aquis
The specific properties of water networks models are determined by the non-linear
head-flow relationships of its components (pipes, pumps, valves and reservoir dynamics).
Some of network nodes have known hydraulic grade elevations; they represent boundary
conditions [4].
The non-linearity of hydraulic models makes the optimization time consuming when
the network becomes large. Actually, the governing laws for flow in pipe systems under
steady conditions are conservation of mass and conservation of energy.
Conservation of mass
As described in [7], the law of conservation of mass states that the rate of storage in a system is equal to the difference between the inflow and outflow to the system. In pressurized
water distribution networks, no storage can occur within the pipe network, although tank
storage may change over time. Therefore, in a pipe, another component or a node (the
inflow and outflow) must balance.
The equilibrium of volumetric flow rates of all pipes connected to the node is calculated
using the following equation
j
Np
X
Qji = qj
i=1
Qji
where
= flow in pipe i connected to node j
12
(2.1)
qj = demand at node j
Npj = number of pipes connected to node j
The value of Q is positive for pipe inflows to the node and negative for pipe outflows from
the node.
Conservation of energy
Also according to [7], conservation of energy states that the difference in energy between
two points is equal to the frictional and minor losses, and the energy added to the flow in
components between these points. An energy balance can be written for paths between
the two end points of a single pipe, between two fixed-grade nodes through a series of
pipes, valves and pumps, or around a loop that begins and ends at the same point. In a
general form for any path,
X
hL,i +
X
hp,j = ∆E
(2.2)
j∈Npu
i∈Np
where
hL,i = head loss across component i along the path
hp,j = head added by pump j
∆E = difference in energy between the end points of the path
Np = number of pipes in the path
Npu = number of pumps in the path
Signs are applied to each term in equation (2.2) to account for the direction of flow. A
common convention is to determine flow directions relative to moving clockwise around
the loop. A pipe or another element of energy loss with flow in the clockwise direction
would be positive in Equation (2.2), and flows in the counterclockwise direction are given
a negative sign. A pump with flow in the clockwise direction would have a negative sign
in Equation (2.2), whereas counterclockwise flow in a pump would be given a positive
sign.
Head loss in pipes can be expressed by a number of empirical formulas. The general
relationship is of the form
hL = rQn
(2.3)
where
r = pipe resistance
Pipe resistance is only dependent on pipe characteristics (roughness, diameter and length)
The following formulas are the most used in network simulators:
Darcy-Weisbach formula
hL =
8f L 2
Q
gD5 π 2
13
(2.4)
where
hL = head loss due to friction (L)
f = Darcy-Weisbach friction factor
g = gravitational acceleration constant (L/T2 )
Q = pipeline flow rate (L3 /T)
Hazen-Williams formula
hL =
Cf L
Q1.852
1.852
C
D4.87
(2.5)
where
hL = head loss due to friction (L)
L = pipe length (L)
C = Hazen-Williams C-factor
D = diameter (L)
Q = pipeline flow rate (L3 /T)
Cf = unit conversion factor (4.73 English, 10.7 SI)
Chezy-Manning formula
hL =
Cf Ln2 2
Q
D5.33
(2.6)
where
hL = head loss due to friction (L)
Cf = unit conversion factor (4.66 English, 10.29 SI)
L = pipe length (L)
n = Manning roughness coefficient
D = diameter (L)
Q = pipeline flow rate (L3 /T)
Relationship between head loss and flow can also be written as follows
Q = khm
L
(2.7)
where
Q = the flow
hL = head loss
m = 1/n
k is the pipe conductance
k = 1/rm (r is the pipe resistance)
In addition to pipes, water networks contain pumps and valves. Common equations for
approximating a pump curve are
hp = AQ2 + BQ + C
14
(2.8)
where Q is the flow and A,B, and C are constants
Head loss in valves and other fittings is of the form [7]
hm =
kv
Q2
2
2gA
(2.9)
where hm is the head loss, A is the flow section, kv is an empirical coefficient and Q is the
flow
The equations described above are used for the resolution of the optimization problem.
Thus if the number of equations is reduced, the resolution will be less time consuming.
This is realized through network simplification. Not all the equations will serve the simplification. Only pipe resistance and pipe conductance are computed and modified (this
will be described further in this document). Note that their expressions differ depending
on formula used.
2.2
Water network simulation
The simulator is used as a ”virtual reality” to represent the behavior of a water network.
There are two kinds of simulation; steady-state and extended-period simulation.
A steady-state simulation computes the state of the system considering that hydraulic demands and boundary conditions do not change with time.
An extended-period simulation computes the varying state of the system through a period of time by computing a series of steady-state simulations.
Using the fundamental concepts of these two types of simulation, more advanced simulations can be built; water quality simulations, automated fire flow analyses, cost analyses
and transient analyses [4].
In this work, simulations are performed to validate the simplification tool. Both steadystate and extended-period simulations will be tested. The focus will be on the second type
of simulation which will be used for pump scheduling.
2.3
Water network simplification
There are two main ways to simplify a network model [6]:
• Simplification of network model components
The basic types of network components are maintained but some individual network components are combined and replaced.
• Black box simplification
The network model is replaced with an abstract model, which provides the same
functionality with less solution time. The work presented in this report deals with
the first type of simplification.
15
Simplification of network model components:
Also called ”skeletonization”, simplification of network model components is the process
of selecting for inclusion in the model only the parts of the hydraulic network that have a
significant impact on the behavior of the system [3]. The level of skeletonization used depends on the intended use of the model; energy operation studies require minimal detailwhich is the case in this work-, while determining available fire flow at individual hydrants requires the most [4]. Skeletonization is not a single process but several different
low-level element removal processes that must be applied in series to ensure that the demands are logically brought back to their source of supply [4].
These skeletonization techniques are the following:
• Use of equivalent pipes in place of pipes connected in parallel and/or in series
• Deletion of trees
• Removal of excessive pipe segmentation caused by valves and fire hydrants
• Trimming of short pipe segments including dead ends (with no or little demand),
service connections and fire hydrants
• Removal of small-diameter pipes (or low conductance pipes)
• Deletion of closed valves
• Elimination of small capacity tanks
• Reduce nodes with similar head to a single node with the total demand of the node
group
In a simplified model all elements with active controls and measurements remain unchanged, but the number of pipes and nodes is significantly reduced. So, reduced models
include the system’s reservoirs, tanks, pumps, valves and pressure and/or flow monitoring nodes [8].
Overall system demand must remain unchanged in skeleton model. Thus for each transformation, node demands are re-allocated based on an equal distribution of demand or
a weighted distribution based on either pipe length or existing demands at the remaining junctions. If the removed junction has an associated demand, the demand must be
re-allocated to one or both of the junctions at the ends of the new pipe. The equivalent
pipe of two pipes in series or two parallel pipes includes initial pipes characteristics and
demands of related junctions. The trim method removes short dead-end pipes and their
corresponding junctions. As with the pipes in series, any removed junctions that have an
associated demand must be transferred to the demand of the remaining junction [3]. The
following is a description of three types of simplification used in the created tool.
16
(a) Before simplification
(b) After simplification
N2
N1
N3
liA
N2
N1
liB
liA
liC
liB
liD
N4
liC
N5
Q4=10
N3
liD
N4
liE
Q4=24
N5
liE
liF
• Demands in junctions N7 and N8
are transferred to N6
Q6=5
N6
Q7=4
N7
N8
Q8=5
• Resulting demand in N6 is
transferred to N4
Figure 2.3: Removal of trees simplification
Removing trees
It consists of removing dead-end branches that do not contain tanks or reservoirs at the
end. The demands are re-allocated to the closest node which is part of the loop (see Figure
2.3). Thus this removal has no effect on the carrying capacity of the remainder of the
system [4].
Use of equivalent pipe for pipes in series
It consists of combining two pipes in series to form an equivalent pipe. Two pipes are in
series when they share the same node; it is an end node for one of the two pipes and a
start node for the other one. The common node must have no other links connected to it
(see Figure 2.4). The demand of the node in common is split between the two nodes at the
ends of the resulting pipe according to user-specified rules. It can be evenly split or the
distribution can be weighted (length, diameter, resistance...). Length of equivalent pipe is
equal to the sum of the lengths of the two pipes being combined. The head losses of the
two pipes must be maintained through the new pipe. So head loss of the equivalent pipe
is the sum of theses two pipes head losses. This is expressed by resistance (see equation
(2.3)). Resistance of the new pipe is calculated by summing up the old pipes resistances
[6].
rnew = rold,1 + rold,2
(2.10)
Diameter and roughness coefficient are then determined using equation (2.3) accord17
(a) Before simplification
N1
N2
liA
Q1=5
N3
liB
Q2=12
Q3=5
(b) After simplification
N1
N3
liA_liB
Q1=11
Q3=11
• Demand in junction N2 is split between
junctions N1 and N3
• Characteristics of pipe liA_liB are calculated
using resistances of pipes liA and liB
Figure 2.4: Pipes in series simplification
ing to head loss formula chosen. Finally, minor losses and check valves are assigned to
the resulting pipe.
In order to avoid impacting model results when the node removed has a large demand,
a limit on flows can be considered. Thus if the node flow exceeds this limit it will not be
eliminated [4].
Use of equivalent pipe for parallel pipes
It consists of combining two parallel pipes to form an equivalent pipe. Two pipes are in
parallel if they have the same beginning and ending nodes (see Figure 2.5).
Head loss between the nodes must stay the same, only flows are summed. This is
expressed by using pipe conductance (see equation (2.7)). So, equivalent pipe has the
length of one of the two pipes and either the diameter or roughness coefficient of this
same pipe. The pipe conductance of the new pipe can be calculated by summing up the
old pipes conductances [6].
knew = kold,1 + kold,2
(2.11)
Diameter and roughness coefficient are then expressed with equation (2.7) according to
head loss formula chosen. If both pipes have check valves, then the resulting pipe should
also have a check valve.
Simplification process
These three simplifications are applied in series. They are repeated until:
18
(a) Before simplification
N1
N3
liA
liB
(b) After simplification
N3
N1
liA_liB
Characteristics of pipe liA_liB are calculated
using conductances of pipes liA and liB
Figure 2.5: Parallel pipes simplification
• all trees are simplified
• all pipes in series are replaced with their equivalent pipes
• all parallel pipes are replaced with their equivalent pipes
The simplification proposed in this work modifies all pipes and nodes which meet the
conditions described above except pipes and nodes with a measurement or a control. It
does not modify pumps, valves, tanks and reservoirs.
The algorithm will implement two types of tree removal. The first is already implemented, it concerns the removal of the dead end branch without maintaining the head
loss. The second will not only transfer the demand but also add the head loss of the dead
end pipe to its neighboring pipe. This can be done by using the resistance of the pipe like
for pipes in series.
Since the aim of the simplification is the optimization of pump scheduling, normally a
total simplification is appropriate. A verification will be done once the implementation is
finished.
This total simplification would lead to pitfalls if the application is for instance water
quality. In this case some restrictions would be necessary. Some examples:
• pipes that close loops are not removed;
• if pipe removal removes a node with greater than a specified demand, then that
removal action will not be carried out [4];
• large pipes are not simplified.
19
Chapter 3
Water network simplification tool
3.1
Requirements and constraints
The tool created must simplify complex water networks which are described in a text file.
The tool uses this file to retrieve data of the network. This file is specific to Epanet (a
hydraulic simulation tool). However, the hydraulic simulation tool used in this project is
Aquis (company’s tool). Export of this file from Aquis has some limitations especially for
controls and measurements. This is why part of the data must be retrieved from an Excel
file also exported from Aquis. The simplification tool must return a new input file where
data of simplified model is summarized. This simplified model must meet all the requirements of the detailed model. To ensure this, simulations for same operating points must
be performed for both detailed and simplified models. Then, the results are compared in
order to validate the simplification tool.
3.2
Description of the input file
The input file has the format of input files of Epanet software (see Figure 3.1). It is organized in sections. Each section starts with a keyword between brackets. These keywords
are listed below (Table 3.1) (see Epanet user guide). The order of sections is not important
but each cited element must have been defined before. Each section has one or more lines
of data. Blank lines can appear anywhere in the file and the semicolon (;) is used to indicate that what follows on the line is a comment, not data. A maximum of 255 characters
can appear on a line. The ID labels used to identify nodes, links, curves and patterns can
be any combination of up to 15 characters and numbers.
All sections are described in detail in the Epanet user guide (Epanet is public domain
software), some of them are described in the appendix. In this work, we are not interested
in water quality, so sections related to water quality will not be described. Besides, some
sections are not exported from Aquis. Table 3.2 lists used sections and determines if any
modification is required. The second column lists the sections that are not exported from
Aquis, these are excluded. The third column lists the sections that does not change after
simplification. In the fourth column, ”Elements can be modified” means that for some
lines, data can change. For example, in section [DEMANDS] the flow can change for an
20
; -----------------------------------------------------------------------------------------------------------------------------------; Model exported from Aquis on 21/06/2013 14:00:16 - C:\Users\SCHNEIDER\Documents\test.inp
;
; -----------------------------------------------------------------------------------------------------------------------------------; ---- The following warnings were generated during export ----------------------------------------------------; -----------------------------------------------------------------------------------------------------------------------------------;
; Unsupported control: Pump L-0010 controls DWS pressure - Value 655264.2688
; Unsupported control: Node INLET has a conditional control
;
; ----------------------------------------------------------------------------------------------------------------------------------[TITLE]
Model exported from Aquis on 21/06/2013 14:00:16 - C:\Users\SCHNEIDER\Documents\test.inp
[OPTIONS]
; --------------------------------------------------------------------------------------------------; Network Properties & Simulation Options
; --------------------------------------------------------------------------------------------------UNITS LPS
HEADLOSS D-W
PATTERN 1
[PIPES]
; ----------------------------------------------------------------------------------------------------------------------------;
Head
Tail
(m)
(mm)
Roughness (Minor Loss (Check
; ID
Node
Node
Length Diameter Coefficient Cofficient)
Valve)
; ----------------------------------------------------------------------------------------------------------------------------L-0680 BLYDE10 BLYDE17 100
80
25
0
OPEN ;
P-0761 HOBSVT HOKARP 300
100
0.25
0
CLOSED ;
[JUNCTIONS]
; --------------------------------------------------------------------------------------------------; ID
Elevation(m)
; --------------------------------------------------------------------------------------------------BLYDE10 43.36000061 ;
Figure 3.1: Input file format
Network
System
Water
Options and
Network
components
operation
quality
reporting
Map/Tags
[TITLE]
[CURVES]
[QUALITY]
[OPTIONS] [COORDINATES]
[JUNCTIONS] [PATTERNS] [REACTIONS]
[TIMES]
[VERTICES]
[RESERVOIRS]
[ENERGY]
[SOURCES]
[REPORT]
[LABELS]
[TANKS]
[STATUS]
[MIXING]
[BACKDROP]
[PIPES]
[CONTROLS]
[TAGS]
[PUMPS]
[RULES]
[VALVES]
[DEMANDS]
[EMITTERS]
Table 3.1: Input file sections
21
Section
Not exported Unchanged Elements can
Lines can
Lines can
from Aquis
be modified be removed be added
[CONTROLS]
x
[COORDINATES]
x
[CURVES]
x
[DEMANDS]
x
x
x
[EMITTERS]
x
[ENERGY]
x
[JUNCTIONS]
x
x
x
[LABELS]
x
[MIXING]
x
[OPTIONS]
x
[PATTERNS]
x
[PIPES]
x
x
x
[PUMPS]
x
[QUALITY]
x
[REACTIONS]
x
[REPORT]
x
[RESERVOIRS]
x
[RULES]
x
[SOURCES]
x
[STATUS]
x
[TAGS]
x
[TANKS]
x
[TIMES]
x
[TITLE]
x
[VALVES]
x
x
[VERTICES]
x
Table 3.2: Modifications of input file sections
existing demand. In the fifth column ”lines can be removed” means that for a specific
section, an element can be removed. For example, in section [JUNCTIONS] a junction can
be removed by removing all its attributes. In the last column ”lines can be added” means
that a new element can be created. For example, when creating an equivalent pipe for two
pipes in series, a new pipe appears in the section.
22
3.3
Class diagram
Based on input file data, the class diagram of Figure 3.2 is defined. Some attributes and
methods not found in the input file data were added because of computing needs. For
example, for class WaterNetwork, method createLinkNodeArray() allows to have in the
same array all links with their related beginning and ending nodes.
The main class is WaterNetwork. A water network is composed of many elements,
these are represented by the class Component. A Component is either a node or a link.
This is represented by inheritance where Component is the base class and the derived
classes are Node and Link. A node is itself a tank or a reservoir or a junction. This is also
represented by an inheritance, Node is the base class and the derived classes are Reservoir,
Tank and Junction. In the same way, Link is a base class and Pipe, Valve and Pump are
derived classes. All these network elements have some characteristics expressed in the
attributes and methods of their corresponding classes. The other characteristics are put
in other classes like Coordinate, Vertice, Demand, Pattern, Curve and Control. Classes
SimulationTimes and Options describe the hydraulic characteristics of the simulation. Not
all classes of the diagram are implemented, this is explained in the next section.
23
WaterNetwork
+ title : string
1
+ createLinkNodeArray()
+ nodesNumber()
+ linksNumber()
+ junctionsNumber()
+ pipesNumber()
+ tanksNumber()
+ reservoirsNumber()
+ pumpsNumber()
+ valvesNumber()
Status
OPEN
CLOSED
CV
1
HeadLoss
ValveTypes
H-W
D-W
C-M
PRV
PSV
PBV
FCV
TCV
GPV
CurveType
Unit
PUMP
EFFICIENCY
VOLUME
HEADLOSS
CFS
GPM
MGD
IMGD
AFD
LPS
LPM
MLD
CMH
CMD
1
1
1
3..*
SimulationTimes
Options
Component
+ duration : double
+ hydTimeStep : float
+ patternTimeStep : float
+ patternStart : float
+ startClocktime : double
+ coordinate
Coordinate
+ x : double
+ y : double
Vertice
1
+ unit : Unit
+ headLoss : HeadLoss
+ defaultPattern : string
+ demandMultiplier : float
+ flowMeasure : float [0..1]
+ pressureMeasure : float [0..1]
+ /isModified : boolean
+ /isDeleted : boolean
+ modifNumberDE : integer
+ modifNumberPS : integer
+ modifNumberPP : integer
+ vertices
0..1
Control
+ control
+ statement : string
0..1
1
SimpleControl
+ isSimplifiable()
+ isMeasured()
RuleBasedControl
+ ruleId : string
+ rulePriority : integer
*
0..1
0..1
Description
Node
24
Coordinates x and y: required if tank or
reservoir, optional if junction
Link
+ links
+ nodes
+ /countStartNode : integer
+ /countEndNode : integer
+ /relatedPipesNumber : integer
2
*
Description
minorLossCoef assumed 0
if no value
+ /startNodeId : string
+ /endNodeId : string
+ statusOrSetting : string [0..1]
+ pipe
1
Description
Pipe
Junction
Reservoir
+ elevation : float
+ totalDemandFlow : float [0..1]
+ totalDemandPattern : string
+ totalHead : float
+ reservoir
Description
Tank
Valve
+ pipeLength : float
+ pipeDiameter : float
+ roughnessCoef : float
+ minorLossCoef : float [0..1]
+ pipeInitStatus : Status [0..1]
+ elevation : float
+ initLevel : float
+ minLevel : float
+ maxLevel : float
+ diameter : float
+ minVolume : float
0..1
1
If a Demand object is related to a
junction, totalDemandFlow and
totalDemandPattern are ignored
+ tank
+ valve
1
Pump
+ pumpPower : float [0..1]
+ pumpSpeed : float [0..1]
1
SingleDemand
ValveGPV
can be any value if there is
a VolumeCurve
0..1
+ diameter : float
+ type : ValveTypes
+ lossCoef : float
+ resistance()
+ conductance()
Description
+ demands
Demand
ValveNonGPV
*
+ valveSetting : string
CurvePoint
Curve
+ curvePoints
+ type : string
+ demandPattern
1
+ valveSetting : float
pipeInitStatus assumed OPEN
if no value
optional if there is a
VolumeCurve
1
+ pump
Description
Description
+ flow : double
+ pattern : string [0..1]
+ category : string [0..1]
valveLossCoef has a value when the
valve is completely opened. Assumed
0 if left blank
+ x : double
+ y : double
1..*
*
1
+ pattern
+ headPattern
0..1
0..1
1
+ pumpPattern
+ pumpCurve
+ valveHeadLossCurve
+ tankVolumeCurve
Pattern
+ patternValue
1..*
PatternValue
0..1
0..1
volumeCurve
HeadLossCurve
0..1
EfficiencyCurve
+ multiplier : float
0..1
+ pumpEfficiencyCurve
Figure 3.2: Class diagram
0..1
PumpCurve
Description
Only one of pumpCurve or
pumpPower is required
1
0..1
Start
Retrieve network
data
Perform
simplification
Create input file
of simplified
network
End
Figure 3.3: Overall algorithm - Main steps
3.4
Implementation
The algorithm is implemented in C] programming language. Microsoft development environment Visual Studio 2010 Ultimate with .NET 4.0 Framework was used.
C] programming language was chosen because of the need of a type-safe object-oriented
language and it was highly recommended by an expert programmer in the team.
3.4.1
The algorithm
As shown in Figure 3.3, the algorithm is realized in three steps. First, data is retrieved from
both the input file and the Excel file. Then, simplification of the network is performed.
Finally, an input file is created for the simplified model obtained.
3.4.2
Parsing the input file
It consists of:
• Opening the input file
• Creating and opening the output file
• Writing a header in the output file
25
• Reading the input file line by line until no line is left
• For each line do the following :
If the line contains any of the following keywords ([COORDINATES], [DEMANDS],
[JUNCTIONS], [PIPES], [TITLE], [VALVES] and [VERTICES]), a specific treatment is done
corresponding to each keyword.
If the previous condition is not satisfied i.e. if the line contains any of the keywords
([CURVES], [OPTIONS], [PATTERNS], [PUMPS], [RESERVOIRS], [TANKS] and [TIMES]),
sections are written without any modification in the output file.
If the line read is a keyword which means the beginning of a section, data are reported
in data structures describing the water network.
These data structures are dictionaries with keys representing the identifiers of the objects,
and the values are objects which implement classes.
Each class represents a real element of the network. There are several objects implementing only one class for each section. For instance, if keyword is [JUNCTIONS], each line
contains attributes of an object Junction. So, these attributes (in this case; identifiers and
elevations) are retrieved and the object Junction formed is added to the dictionary junctionsList. This dictionary contains all junctions of the network.
Since sections [CURVES], [OPTIONS], [TIMES] and [PATTERNS] are not modified,
their corresponding classes in the diagram are not implemented. They are directly copied
in the input file from the initial input file. Note that creation of the input file of the simplified network is done in the first step of the algorithm. The aim is to avoid reading
the input file of the detailed model several times. The modified sections obtained after
simplification are added to the input file already created and partially filled.
3.4.3
Parsing the Excel file
Control and measurements are specified in Excel file. Depending on the element (pipe,
junction...), they are found in different sheets. If an element of the network has a control
or a measurement, it is identified in order to exclude it from the simplification. This step
is not implemented yet.
3.4.4
Simplification process
Before describing the simplification process, the component qualifier ”unsimplifiable”
must be defined. An unsimplifiable component is a node or a link that has to stay during
simplification.
Identification of unsimplified components (this identification starts in Excel file parsing):
• Mark all reservoirs, tanks, pumps and valves as unsimplifiable;
• Mark all pipes and nodes with measurement (pressure and/or flow measurement)
as unsimplifiable;
26
• Mark all controlled nodes and pipes as unsimplifiable;
• Mark all pipes which are connected to unsimplifiable nodes as unsimplifiable as
well;
• Mark the start and end nodes of unsimplifiable links as unsimplifiable.
As mentioned before, only three types of simplifications are used; removal of trees, replacement of pipes in series by an equivalent pipe and replacement of parallel pipes by an
equivalent pipe. It is probably necessary to review the network because one simplification
may create conditions where a previous simplification can be performed. This should be
tested once the three simplifications will be implemented.
Algorithm of tree removal
There is a tree when an end node is related to only one link.
Identification of the end node: for each node in the dictionary nodesList, two attributes
are evaluated: countStartNode and endStartNode.
countStartNode counts how many times the node is a start node.
countEndNode counts how many times the node is an end node.
countStartNode must be equal to 0 and countEndNode must be equal to 1.
Conditions: simplification can be done only if
• end node is simplifiable (node=junction, node6=reservoir, node6=tank, no control, no
measurement)
• related link is simplifiable (link=pipe, link6=valve, link6=pump, no control, no measurement)
• related start node is simplifiable
If previous conditions are met, start simplification;
• Demand of end node is added to demand of start node;
• countStartNode of start node is decremented
• Related link is removed from sections [PIPES] and [VERTICES], it is also removed
from all dictionaries where it can be found (recall that dictionaries are data structures
used for modifying sections of input file);
• Dead end node is removed from sections [JUNCTIONS], [DEMANDS] and [COORDINATES], it is also removed from all dictionaries where it can be found.
27
Algorithm of equivalent pipe for pipes in series
Pipes are in series if they share the same node and this node is not connected to other
links.
Identification of the common node: each node in the dictionary nodesList must have a
relatedPipesNumber equal to 2. relatedPipesNumber counts the number of pipes a node
is related to.
Conditions: simplification can be done only if
• Common node is simplifiable (node=junction, node6=reservoir, node6=tank, no control, no measurement);
• Two links are simplifiable (link=pipe, link6=valve, link6=pump, no control, no measurement);
• Start node of one pipe (which will be the start node of equivalent pipe) and end
node of the second pipe (which will be the end node of equivalent pipe) are both
simplifiable.
If previous conditions are met, start simplification;
• Compute equivalent pipe characteristics (start node, end node, length, roughness
coefficient, diameter, resistance) based on those of two pipes being simplified;
• Distribute demand of common node to new start and end nodes. Currently demand
is all transferred to start node, this must be improved later. A rule for distributing
demands must be established);
• Delete two links from sections [PIPES] and [VERTICES];
• Delete common node from sections [JUNCTIONS], [DEMANDS] and [COORDINATES].
Algorithm of equivalent pipes for parallel pipes
Parallel pipes have the same start node and the same end node.
Conditions: simplification can be done only if
• Two links are simplifiable (link=pipe, link6=valve, link6=pump, no control, no measurement)
If previous condition is met:
• Compute equivalent pipe characteristics (start node, end node, length, roughness
coefficient, diameter, resistance) based on those of two pipes being simplified
• Delete two pipes from sections [PIPES] and [VERTICES]
28
This simplification has not been implemented yet.
These three algorithms should be applied iteratively till all simplifications are done.
To reduce iterations over the dictionary nodesList several times, the conditions of tree
removal and pipes in series are checked simultaneously in one pass.
3.4.5
Preliminary results
The algorithm as it is currently implemented includes the two first types of simplifications.
It was applied to Birkerod water network. This network serves 22 000 consumers.
It consists of 648 junctions and 742 pipes. After simplification, only 306 junctions and 400
pipes remain in the network. Which is a very encouraging result.
This result will be improved when the algorithm will be totally implemented.
29
Conclusion
In this report, a method of automated simplification of water networks was presented. It
concerns the topological reduction of the network. The tool that performs this simplification was implemented in C] language using Visual Studio 2010.
Before simplifying, it was necessary to retrieve data from an input file. After data was
put in data structures such that modifications could be applied on the network, simplified
model was written back in the same format of input file.
The time spent to learn how to use simultaneously two hydraulic simulation software
was longer than expected. Aquis was the software required, but the format of input file is
given by Epanet. Aquis permits the export of network in this format. Thus it was necessary to take into account export limitations.
The most difficult was to start from scratch and to think for a solution from both hydraulics side and software engineering side. Specification stage was longer than implementation. Thus implementation is not totally finished.
Future work
The future works should cover the following aspects:
Code completion
Implementation of the tool is not complete. The following is a list of what still has to be
done:
• Parsing Excel file in order to (i) mark all unsimplifiable links and nodes, (ii) retrieve
all condition controls and add them to the input file in [CONDITIONS] and [RULES]
sections. Note that some conditions on pumps and valves of Aquis are not supported in input file. A solution must be found to retrieve these data;
• Add exceptions in the code, for example if the input file cannot be opened;
• Handle two other formulas of head loss (Hazen-Williams and Chezy-Manning);
• Implement parallel pipes simplification;
30
Verification and testing of simplification tool
Tool must be tested with small, medium and large scale networks. Hydraulic simulation
output must be generated for the three skeletonized models and the corresponding allpipes models in order to make a comparison. Points that must be checked are:
• Correct operational limits of tanks, pumps and valves;
• Tank’s volume evolution reproduced by the simulator must be identical to the real
one.
If differences are too important, try to find errors to improve simplification algorithms.
Search other innovative simplification methods
prepare specifications and eventually realize a mock-up
Personal conclusion
It was interesting to experience working in a large company. It was also a big opportunity
for me to work within a research team. My role within the team consisted of integrating
some hydraulics techniques. As so, I was responsible for the technical choices regarding
my initial specialty. Another good aspect of the internship was learning how to use hydraulic simulators Aquis and Epanet and learning a new programming language which
is C] . Thanks to this program, I am able today to handle a project from specification steps
to development. The master’s courses covered a large number of topics and techniques,
the internship was then a perfect continuity as it enabled handling the practical aspects
studied during the previous months. Moreover, the courses helped me to enhance my
communication skills to better share and work with computer engineering teams.
31
Bibliography
[1] www.arrowhead.eu.
[2] www.schneider-electric.com.
[3] R. Bahadur, J. Johnson, R. Janke, and W.B. Samuels. Impact of model skeletonization
on water distribution model parameters as related to water quality and contaminant
consequence assessment. 8th Annual Water Distribution Systems Analysis Symposium,
Cincinnati, Ohio, USA, 2006.
[4] Haestad Methods, T.M. Walski, D.V. Chase, D.A. Savic, W. Grayman, S. Beckwith,
and E. Koelle. Advanced water distribution modeling and management. Haestad Methods,
Inc., 2003.
[5] R. Klempous, J. Kotowski, J. Nikodem, M. Olesiak, and J. Ulasiewicz. Some models for
water distribution systems. Journal of Computational and Applied Mathematics, 21(3):257–
269, March 1988.
[6] T. Maschler and D.A. Savic. Simplification of water supply network models through
linearisation. Technical report, Center for Water Systems, University of Exeter, UK,
1999.
[7] Larry.W. Mays. Hydraulic design handbook. McGraw-Hill, 1999.
[8] A. Preis, A.J. Whittle, A. Ostfeld, and L. Perelman. Efficient hydraulic state estimation
technique using reduced models of urban water networks. Journal of Water Resources
Planning and Management, 137(4):343351, July 2011. description of Ulanicki et al. algorithm for hydraulic aggregation.
[9] V. Speight and N. Khanal. Model calibration and current usage in practice. Urban
Water Journal, 6(1):23–28, March 2009.
32
Appendix A Sections of input file
The following is a description of the most important elements which can be found in the
input file. It is directly reported from Epanet user manual.
[COORDINATES]
Purpose:
Assigns map coordinates to network nodes.
Format:
One line for each node containing:
• Node ID label
• X-coordinate
• Y-coordinate
Remarks:
a. Include one line for each node displayed on the map.
b. The coordinates represent the distance from the node to an arbitrary origin at the lower
left of the map. Any convenient units of measure for this distance can be used.
c. There is no requirement that all nodes be included in the map, and their locations need
not be to actual scale.
d. A [COORDINATES] section is optional and is not used at all when EPANET is run as a
console application.
Example:
[COORDINATES]
;Node X-Coord. Y-Coord
; - - - - - - - - - - - - - - - - - 1 10023 128
2 10056 95
[CURVES]
Purpose:
Defines data curves and their X, Y points.
Format:
One line for each X, Y point on each curve containing:
•Curve ID label
•X value
•Y value
Remarks:
33
a. Curves can be used to represent the following relations:
•Head v. Flow for pumps
•Efficiency v. Flow for pumps
•Volume v. Depth for tanks
•Head loss v. Flow for General Purpose Valves
b. The points of a curve must be entered in order of increasing X-values (lower to higher).
c. If the input file will be used with the Windows version of EPANET, then adding a
comment which contains the curve type and description, separated by a colon, directly
above the first entry for a curve will ensure that these items appear correctly in EPANET’s
Curve Editor. Curve types include PUMP, EFFICIENCY, VOLUME, and HEADLOSS. See
the examples below.
Example:
[CURVES]
;ID Flow Head
;PUMP: Curve for Pump 1
C1 0 200
C1 1000 100
C1 3000 0 ;ID Flow Effic.
;EFFICIENCY:
E1 200 50
E1 1000 85
E1 2000 75
E1 3000 65
[DEMANDS]
Purpose:
Supplement to [JUNCTIONS] section for defining multiple water demands at junction
nodes.
Format:
One line for each category of demand at a junction containing:
•Junction ID label
•Base demand (flow units)
•Demand pattern ID (optional)
•Name of demand category preceded by a semicolon (optional)
Remarks:
a. Only use for junctions whose demands need to be changed or supplemented from
entries in [JUNCTIONS] section.
b. Data in this section replaces any demand entered in [JUNCTIONS] section for the same
junction.
c. Unlimited number of demand categories can be entered per junction.
a. If no demand pattern is supplied then the junction demand follows the Default Demand
Pattern specified in the [OPTIONS] section or Pattern 1 if no default pattern is specified.
If the default pattern (or Pattern 1) does not exist, then the demand remains constant.
Example:
[DEMANDS]
34
;ID Demand Pattern Category
;--------------------------------J1 100 101 ;Domestic
J1 25 102 ;School
J256 50 101 ;Domestic
[JUNCTIONS]
Purpose:
Defines junction nodes contained in the network.
Format:
One line for each junction containing:
•ID label
•Elevation, ft (m)
•Base demand flow (flow units) (optional)
•Demand pattern ID (optional)
Remarks:
b. A [JUNCTIONS] section with at least one junction is required.
c. If no demand pattern is supplied then the junction demand follows the Default Demand
Pattern specified in the [OPTIONS] section or Pattern 1 if no default pattern is specified.
If the default pattern (or Pattern 1) does not exist, then the demand remains constant.
d. Demands can also be entered in the [DEMANDS] section and include multiple demand
categories per junction.
Example:
[JUNCTIONS]
;ID Elev. Demand Pattern
;-----------------------------J1 100 50 Pat1
[OPTIONS]
Purpose:
Defines various simulation options.
Formats:
UNITS
CFS/GPM/MGD/IMGD/AFD/LPS/LPM/MLD/CMH/CMD
HEADLOSS
H-W/D-W/C-M
PATTERN
id
DEMAND MULTIPLIER
value
Definitions:
UNITS : sets the units in which flow rates are expressed where:
CFS = cubic feet per second
GPM = gallons per minute
MGD = million gallons per day
IMGD = Imperial MGD
AFD = acre-feet per day
LPS = liters per second
LPM = liters per minute
35
MLD = million liters per day
CMH = cubic meters per hour
CMD = cubic meters per day
For CFS, GPM, MGD, IMGD, and AFD other input quantities are expressed in US Customary Units.
If flow units are in liters or cubic meters then Metric Units must be used for all other input
quantities as well. The default flow units are GPM.
HEADLOSS selects a formula to use for computing head loss for flow through a pipe. The
choices are the Hazen-Williams (H-W), Darcy-Weisbach (D-W), or Chezy-Manning (C-M)
formulas. The default is H-W.
PATTERN provides the ID label of a default demand pattern to be applied to all junctions
where no demand pattern was specified. If no such pattern exists in the [PATTERNS]
section then by default the pattern consists of a single multiplier equal to 1.0. If this option
is not used, then the global default demand pattern has a label of ”1”.
The DEMAND MULTIPLIER is used to adjust the values of baseline demands for all junctions and all demand categories. For example, a value of 2 doubles all baseline demands,
while a value of 0.5 would halve them. The default value is 1.0.
Remarks:
a. All options assume their default values if not explicitly specified in this section.
b. Items offset by slashes (/) indicate allowable choices.
Example:
[OPTIONS]
UNITS CFS
HEADLOSS D-W
[PATTERNS]
Purpose:
Defines time patterns.
Format:
One or more lines for each pattern containing:
•Pattern ID label
•One or more multipliers
Remarks:
a. Multipliers define how some base quantity (e.g., demand) is adjusted for each time
period.
a. All patterns share the same time period interval as defined in the [TIMES] section.
b. Each pattern can have a different number of time periods.
c. When the simulation time exceeds the pattern length the pattern wraps around to its
first period.
d. Use as many lines as it takes to include all multipliers for each pattern.
Example:
[PATTERNS]
;Pattern P1
P1 1.1 1.4 0.9 0.7
P1 0.6 0.5 0.8 1.0
36
;Pattern P2
P2 1 1 1 1
P2 0 0 1
[PIPES]
Purpose:
Defines all pipe links contained in the network.
Format:
One line for each pipe containing:
•ID label of pipe
•ID of start node
•ID of end node
•Length, ft (m)
•Diameter, inches (mm)
•Roughness coefficient
•Minor loss coefficient
•Status (OPEN, CLOSED, or CV)
Remarks:
a. Roughness coefficient is unitless for the Hazen-Williams and Chezy-Manning head loss
formulas and has units of millifeet (mm) for the Darcy-Weisbach formula. Choice of head
loss formula is supplied in the [OPTIONS] section.
b. Setting status to CV means that the pipe contains a check valve restricting flow to one
direction.
c. If minor loss coefficient is 0 and pipe is OPEN then these two items can be dropped
from the input line.
Example:
[PIPES]
;ID Node1 Node2 Length Diam. Roughness Mloss Status
;------------------------------------------------------------P1 J1 J2 1200 12 120 0.2 OPEN
P2 J3 J2 600 6 110 0 CV
P3 J1 J10 1000 12 120
[PUMPS]
Purpose:
Defines all pump links contained in the network.
Format:
One line for each pump containing:
•ID label of pump
•ID of start node
•ID of end node
•Keyword and Value (can be repeated)
Remarks:
a. Keywords consist of:
•POWER - power value for constant energy pump, hp (kW)
37
•HEAD - ID of curve that describes head versus flow for the pump
•SPEED - relative speed setting (normal speed is 1.0, 0 means pump is off)
•PATTERN - ID of time pattern that describes how speed setting varies with time
b. Either POWER or HEAD must be supplied for each pump. The other keywords are
optional.
Example:
[PUMPS]
;ID Node1 Node2 Properties
;--------------------------------------------Pump1 N12 N32 HEAD Curve1
Pump2 N121 N55 HEAD Curve1 SPEED 1.2
Pump3 N22 N23 POWER 100
[RESERVOIRS]
Purpose:
Defines all reservoir nodes contained in the network.
Format:
One line for each reservoir containing:
• ID label
• Head, ft (m)
• Head pattern ID (optional)
Remarks:
a. Head is the hydraulic head (elevation + pressure head) of water in the reservoir.
b. A head pattern can be used to make the reservoir head vary with time.
c. At least one reservoir or tank must be contained in the network.
Example:
[RESERVOIRS]
;ID Head Pattern
;--------------------R1 512 ;Head stays constant
R2 120 Pat1 ;Head varies with time
[STATUS]
Purpose:
Defines initial status of selected links at the start of a simulation.
Format: One line per link being controlled containing:
• Link ID label
• Status or setting
Remarks:
a. Links not listed in this section have a default status of OPEN (for pipes and pumps) or
ACTIVE (for valves).
b. The status value can be OPEN or CLOSED. For control valves (e.g., PRVs, FCVs, etc.)
this means that the valve is either fully opened or closed, not active at its control setting.
c. The setting value can be a speed setting for pumps or valve setting for valves.
d. The initial status of pipes can also be set in the [PIPES] section.
38
e. Check valves cannot have their status be preset.
f. Use [CONTROLS] or [RULES] to change status or setting at some future point in the
simulation.
g. If a CLOSED or OPEN control valve is to become ACTIVE again, then its pressure or
flow setting must be specified in the control or rule that re-activates it.
Example:
[STATUS]
; Link Status/Setting
;---------------------L22 CLOSED ;Link L22 is closed
P14 1.5 ;Speed for pump P14
PRV1 OPEN ;PRV1 forced open
;(overrides normal operation)
[TANKS]
Purpose:
Defines all tank nodes contained in the network.
Format:
One line for each tank containing:
• ID label
• Bottom elevation, ft (m)
• Initial water level, ft (m)
• Minimum water level, ft (m)
• Maximum water level, ft (m)
• Nominal diameter, ft (m)
• Minimum volume, cubic ft (cubic meters)
• Volume curve ID (optional)
Remarks:
a. Water surface elevation equals bottom elevation plus water level.
b. Non-cylindrical tanks can be modeled by specifying a curve of volume versus water
depth in the [CURVES] section.
c. If a volume curve is supplied the diameter value can be any non-zero number
d. Minimum volume (tank volume at minimum water level) can be zero for a cylindrical
tank or if a volume curve is supplied.
e. A network must contain at least one tank or reservoir.
Example:
[TANKS]
;ID Elev. InitLvl MinLvl MaxLvl Diam MinVol VolCurve
;----------------------------------------------------------;Cylindrical tank
T1 100 15 5 25 120 0
;Non-cylindrical tank with arbitrary diameter
T2 100 15 5 25 1 0 VC1
[TIMES]
39
Purpose:
Defines various time step parameters used in the simulation.
Formats:
DURATION Value (units)
HYDRAULIC TIMESTEP Value (units)
QUALITY TIMESTEP Value (units)
RULE TIMESTEP Value (units)
PATTERN TIMESTEP Value (units)
PATTERN START Value (units)
REPORT TIMESTEP Value (units)
REPORT START Value (units)
START CLOCKTIME Value (AM/PM)
STATISTIC NONE/AVERAGED/MINIMUM/MAXIMUM RANGE
Definitions:
DURATION is the duration of the simulation. Use 0 to run a single period snapshot analysis. The default is 0.
HYDRAULIC TIMESTEP determines how often a new hydraulic state of the network is
computed. If greater than either the PATTERN or REPORT time step it will be automatically reduced. The default is 1 hour.
QUALITY TIMESTEP is the time step used to track changes in water quality throughout
the network. The default is 1/10 of the hydraulic time step.
RULE TIMESTEP is the time step used to check for changes in system status due to activation of rule-based controls between hydraulic time steps. The default is 1/10 of the
hydraulic time step.
PATTERN TIMESTEP is the interval between time periods in all time patterns. The default
is 1 hour.
PATTERN START is the time offset at which all patterns will start. For example, a value of
6 hours would start the simulation with each pattern in the time period that corresponds
to hour 6. The default is 0.
REPORT TIMESTEP sets the time interval between which output results are reported. The
default is 1 hour.
REPORT START is the length of time into the simulation at which output results begin to
be reported. The default is 0.
START CLOCKTIME is the time of day (e.g., 3:00 PM) at which the simulation begins. The
default is 12:00 AM midnight.
[TITLE]
Purpose:
Attaches a descriptive title to the network being analyzed.
Format:
Any number of lines of text.
Remarks:
The [TITLE] section is optional.
40