A software tool for assessing the performance of and implementing water distribution system solution methods

A software tool for assessing the performance of and implementing water distribution system solution methods

Accepted Manuscript A software tool for assessing the performance of and implementing water distribution system solution methods Mengning Qiu, Bradley...

2MB Sizes 3 Downloads 47 Views

Accepted Manuscript A software tool for assessing the performance of and implementing water distribution system solution methods Mengning Qiu, Bradley Alexander Angus R, Simpson Sylvan Elhay PII:

S1364-8152(18)30416-X

DOI:

https://doi.org/10.1016/j.envsoft.2018.10.016

Reference:

ENSO 4335

To appear in:

Environmental Modelling and Software

Received Date: 2 May 2018 Revised Date:

8 October 2018

Accepted Date: 27 October 2018

Please cite this article as: Qiu, M., Angus R, B.A., Elhay, S.S., A software tool for assessing the performance of and implementing water distribution system solution methods, Environmental Modelling and Software (2018), doi: https://doi.org/10.1016/j.envsoft.2018.10.016. This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

A Software Tool for Assessing the Performance of and Implementing Water Distribution System Solution Methods Mengning Qiu∗

RI PT

Bradley Alexander Angus R. Simpson Sylvan Elhay University of Adelaide, South Australia, 5005

SC

Highlights

M AN U

• A library for the steady-state analysis of a water distribution system (WDS) • An open-source C++ software implementation of a number of WDS solution methods. • A fast simulation platform for both once-off and multi-run simulations • Several improvements to the existing solution methods have been made.

TE D

Abstract

WDSLib is an extensible simulation toolkit for the steady-state analysis of a water distribution system. It includes a range of solution methods: the forest-core partitioning algorithm, the global gradient algorithm, the reformulated co-tree flow method, and also combinations of these methods.

EP

WDSLib has been created using a modularized object-oriented design and implemented in the C++ programming language, and has been validated against a reference MATLAB implementation. WDSLib has been designed: (i) to avoid unnecessary computations by hoisting each of the modules to

AC C

its appropriate level of repetition, (ii) to perform the computations independently of measurement units using scaled variables, (iii) to accurately report the execution time of all the modules in that it is possible to produce a timing model to parameterize multiple simulation times (such as in an optimization using a genetic algorithm) from a series of sampling simulation runs and (iv) to guard against numerical failures. Two example applications, a once-off simulation and a network optimization design application simulation, are presented. This toolkit can be used (i) to implement, test and compare different solution methods, (ii) to focus the research on the most time-consuming parts of a solution method and (iii) to guide the choice of solution method when multiple simulation runs are required. ∗ Corresponding Author Email: [email protected]

1

ACCEPTED MANUSCRIPT Keywords: Water Distribution System; C++ toolkit; Object-Oriented design; Forest-Core Partitioning Algorithm; Reformulated Co-tree Flows Method; Global Gradient Algorithm; open source software

Software availability

2

Name of the Software: WDSLib

3

Version: 1.0

4

Available from: https://github.com/a1184182/WDSLib

5

Language: C++

6

Supported System: Windows, MacOS, Linux, Unix

7

Year first available: 2018

8

1 Introduction

9

Hydraulic simulation has been used to model water distribution systems (WDSs) for several decades

10

and is an essential tool for the design, operation, and management of WDSs in industry and research.

11

Hydraulic simulation allows users (1) to optimize WDS network parameters, such as pipe diameters,

12

in a design setting, (2) to calibrate network parameters, such as demand patterns, in a conventional

13

operational setting, (3) to conduct real-time monitoring and calibration of the network elements in a

14

supervisory control and data acquisition (SCADA) operational setting, and (4) to adjust control devices,

15

such as valves, in a management setting. In the design setting and both the above operational settings,

16

repeated hydraulic assessment is required on a network with fixed topology. In the management setting,

17

repeated hydraulic assessment is required on a network with flexible network parameter settings. With

18

ever-increasing network sizes and the need for real-time management using a SCADA system, it is

19

important to have a robust simulation package which can be configured to be maximally efficient whatever

20

the setting.

AC C

EP

TE D

M AN U

SC

RI PT

1

21

In the field of hydraulic simulation, the system of equations can be formulated as a large and sparse

22

non-linear saddle point problem. Saddle point problems are defined to be a function of two variables (say

23

f(q,h)) and the objective is to find a pair of variables (q*,h*) such that the value f(q*,h*) is minimized

24

with respect to the first variable and maximized with respect to the second variable or equivalently,

25

f (q∗, h) < f (q∗, h∗) < f (q, h∗)∀q, h. There are several well-known iteration methods for solving the non-

26

linear saddle point problem. These include: range space methods, a method that operates in the subspace

27

defined by the rows of the unknown-head node-arc incidences matrix, (Global Gradient Algorithm (Todini

28

and Pilati 1988)), Null space methods, a method that operates in the subspace defined by a null-space that

29

is orthogonal to the column of the unknown-head node-arc incidences matrix (Co-Tree flow formulation 2

ACCEPTED MANUSCRIPT variations (Rahal 1995; Elhay et al. 2014)), loop-based methods, a method is based on the sum of head

31

losses around a loop must be zero (Loop flow correction (Cross 1936)), and pre-and-post-processing

32

methods (forest-core partitioning algorithm (Simpson et al. 2014), domain decomposition (Diao et al.

33

2014), network clustering (Perelman and Ostfeld 2011)). Their relative performance in terms of speed,

34

rate-of-convergence, and accuracy depends among other things on the topology of the target network:

35

size of the forest component, the number of network loops, and the density of these network loops.

36

It is difficult to evaluate the impact of these topology factors by only examining the incidence matrix

37

that describes the pipe network connectivity. As a result, the best method to use for a particular

38

network cannot be easily determined a priori. Moreover, extra complexity is introduced when a multi-

39

run hydraulic assessment is required. During a multi-run hydraulic simulation, the elapsed computation

40

time of each method can be broken down into two parts: the components that are only required to be

41

performed once at the very beginning for the same network, called the overhead, and the components that

42

are required to be carried out repeatedly for each separate run until the required number of iterations has

43

been met, called the hydraulic-phase. It is desirable to have a simulation platform, given the different

44

levels of repetition, to implement these alternative algorithms efficiently. Equipped with such a platform

45

a user would be able to easily benchmark the performance of alternative methods on a small number

46

of evaluations for a given network and use that performance to inform the choice of algorithm to use

47

for either a once-off simulation setting or for a multiple simulation setting (such as for an evolutionary

48

algorithm (EA)).

TE D

M AN U

SC

RI PT

30

This work describes an extensible WDS simulation platform called WDSLib. WDSLib is a numerically

50

robust, efficient and accurate C++ library that implements many WDS simulation methods. WDSLib is

51

written using a modular object-oriented design which allows users to easily mix and interchange solution

52

components, thereby enabling users to avoid redundant computations. It has been optimized to use

53

sparse data structures which are oriented to the pattern of access required for each solution method.

54

WDSLib has been validated for accuracy on a range of realistic benchmark water distribution networks

55

against reference implementations and tested for speed. The program accepts the input file formats of

56

the industry standard EPANET2 (Rossman 2000) toolkit and its performance is faster than EPANET2

57

in all tested settings and benchmarks.

AC C

EP

49

58

The remainder of this paper is structured as follows. The next section describes related methodologies

59

and implementations. A general description of the WDS demand-driven steady-state problem is given

60

in the next section. Section 3 presents a mathematical formulation of the network and the solution

61

methods that are used in WDSLib. The tool-kit structure is then given in section 4. This is followed,

62

in section 5, by the toolkit implementation details. Section 6 provides some examples of how the toolkit

63

can be utilized in a simulation work flow. The results are discussed in Section 7. Finally, section 8

64

summarizes the results of this paper and describes future extensions to the toolkit.

3

ACCEPTED MANUSCRIPT

2 Background

66

This section describes related water distribution system network solution methods and implementations.

67

The first sub-section describes solution methods, including those used by WDSLib. This is followed by

68

a description of currently available implementations and compares these with WDSLib.

69

2.1 Related Methods

70

This research considers a water distribution model made up of energy conservation equations and the

71

demand driven model continuity equations. The Hardy Cross method (Cross 1936), also known as the

72

loop flow corrections method, is one of the oldest methods and uses successive approximations, solving for

73

each loop flow correction independently. It is a method that was widely used for its simplicity at the time

74

when it was introduced. More than three decades later, Epp and Fowler (1970) developed a computer

75

version of Cross’s method and replaced the numerical solver with the Newton method, which solves for

76

all loop flow corrections simultaneously. However, this method has not been widely used because of the

77

need (i) to identify the network loops, (ii) to find initial flows that satisfy continuity and (iii) to use

78

pseudo-loops.

M AN U

SC

RI PT

65

The GGA is a range space method that solves for both flows and heads. It was the first algorithm, in

80

the field of hydraulics, to exploit the block structure of the Jacobian matrix to reduce the size of the key

81

matrix in the linearization of the Newton method. The GGA has gained popularity through its rapid

82

convergence rate for a wide range of starting values. This is the result of using the Newton method on

83

an optimizations problem that has a quadratic surface. However, it was reported by Elhay and Simpson

84

(2011) that the GGA fails catastrophically in the presence of zero flows in a WDS when the head loss

85

is modeled by the Hazen-Williams formula. Regularization methods have been proposed by both Elhay

86

and Simpson (2011) and Gorev et al. (2012) to deal with zero flows when the head loss is modeled by

87

the Hazen-Williams formula.

EP

TE D

79

The GGA as it was first proposed, applied only for the WDSs in which the head loss is modeled by the

89

Hazen-Williams formula, where the resistance factor was independent of flow. Rossman (2000) extended

90

the GGA to allow the use of the Darcy-Weisbach formula. It has been pointed out in Simpson and Elhay

91

(2010), however, that Rossman incorrectly treated the Darcy-Weisbach resistance factor as independent

92

of the flow. They introduced the correct Jacobian matrix to deal with this. It has been demonstrated

93

that once the correct Jacobian matrix is used, the quadratic convergence rate of the Newton method is

94

restored. Furthermore, Elhay and Simpson (2011) reported that the GGA does not fail in the presence

95

of zero flows when the derivatives of the Darcy-Weisbach Jacobian matrix are correctly computed for

96

laminar flows.

97

AC C

88

The co-trees flow method (CTM) (Rahal 1995) is a null space method that solves for the co-tree

4

ACCEPTED MANUSCRIPT flows and spanning tree flows separately. The CTM, unlike the loop flow corrections method, does

99

not require the initial flows to satisfy continuity. However, it does require: (i) the identification of

100

the associated circulating graph; (ii) the determination of the demands that are to be carried by tree

101

branches; (iii) finding the associated chain of branches closing a circuit for each co-tree chord; (iv)

102

computing pseudo-link head losses. The reformulated co-trees flow method (RCTM) (Elhay et al. 2014)

103

is also a null space method that solves for co-tree flows and spanning trees flows separately. It represents

104

a significant improvement on the CTM by removing requirements (i) to (iv) above. It uses the Schilders’

105

factorization (Schilders 2009) to permute the node-arc incidence matrix into an invertible spanning tree

106

block and a co-tree block. This permutation reduces the dimension of the Schur complement from being

107

equal to the number of junctions (as in the GGA) to approximately the number of loops in the network.

108

Abraham and Stoianov (2015) proposed a novel idea to speed-up the solution process when using a

109

null space method to solve a WDS network. Their idea exploits the fact that a significant proportion of

110

run-time is spent computing the head losses. At the same time, flows within some pipes exhibit negligible

111

changes after a few iterations. As a result, there is no point in wasting computer resources to re-compute

112

the pipe head losses for the pipes that have little or no change in flows. This partial update can be used

113

to economize the computational complexity of the GGA, the RCTM and their variations.

M AN U

SC

RI PT

98

The forest-core partitioning algorithm (FCPA) (Simpson et al. 2014) speeds up the solution process

115

in the case where the network has a significant forest component. This algorithm permutes the system

116

equations to partition the linear component of the problem, which is the forest of the WDS, from the

117

non-linear component, which is the core of the WDS. It can be viewed as a method that simplifies the

118

problem by solving for the flows and the heads in the forest just once instead of at every iteration. The

119

FCPA reduces the number of pipes, number of junctions, and the dimension of the Jacobian matrix in

120

the core by the number of forest pipes (or nodes).

EP

TE D

114

The graph matrix partitioning algorithm(GMPA) (Deuerlein et al. 2015) exploited the linear relation-

122

ships between flows of the internal trees within the core and the flows of the corresponding super-links

123

after the forest of the network has been removed. This was a major breakthrough. The GMPA permutes

124

the node-arc incidence matrix in such a way that all of the nodes with degree two in the core can be

125

treated as a group. By partitioning the network this way, the network can be solved by a global step,

126

which solves for the nodes with degree greater than two (super nodes) and the pipes which connect to

127

them (path chords), and a local step, which solves for the nodes with degree two (interior path nodes)

128

and pipes connected to them (path-tree links).

129

2.2 Related Implementations

130

EPANET 2 (Rossman 2000) is a widely used WDS simulation package. EPANET 2 implemented the

131

GGA to provide a demand-driven steady-state solution of a WDS. The code for EPANET 2 is in the

AC C

121

5

ACCEPTED MANUSCRIPT 132

public domain, allowing many extensions to be developed. Currently available extensions include: the

133

implementation of a pressure-dependent model (Cheung et al. 2005; Morley and Tricarico 2008; Siew and

134

Tanyimboh 2012; Jun and Guoping 2012) and a real-time simulation capability (Vassiljev and Koppel

135

2015). The EPANET 2 implementation is not explicitly designed to necessarily be easy to understand or ac-

137

commodate alternative solution methods (Guidolin et al. 2010). The elements that are used in EPANET

138

2 are stored by the variables that describe their graph properties. For example, (1) junctions, reservoirs,

139

and tanks are stored as a C struct called Node and (2) all valves, pipes, and pumps are stored as a C

140

struct called Link. The abundant use of global variables limits the reusability and the possibility of the

141

thread-safe design (Guidolin et al. 2010).

RI PT

136

Consequently, it is difficult to cleanly incorporate new solution methods into EPANET 2 in a manner

143

that allows a fair comparison of performance between these methods. Moreover, because there are no

144

clearly defined interfaces for the incorporation of third-party code components in EPANET 2, there is

145

no guarantee that independently authored extensions will be easy to combine with each other.

M AN U

SC

142

In the absence of a popular easy-to-modify WDS simulation platform there is currently no straight-

147

forward means for comparing different solution methods. To date, when new solution methods have

148

been developed they have been compared using different research systems, on different platforms with

149

different implementation languages. This leads to difficulty in comparing methods, limits the reusability

150

of code, and creates a barrier for researchers to reproduce and replicate results. To address these is-

151

sues, an extensible framework is required that allows implementation of new methodologies to be easily

152

incorporated without an adverse impact on the performance of the rest of the system.

TE D

146

To this end, a number of attempts have been made to implement an object-oriented wrapper to

154

encapsulate the EPANET 2 solver (openNet (Morley et al. 2000) and OOTEN(van Zyl et al. 2003)).

155

However, these two systems were focused on providing more flexibility in the processing of input to the

156

core EPANET solver. They did not address any issues relating to the solution process. CWSnet, a C++

157

implementation in object-oriented style, was produced by Guidolin et al. (2010) as an alternative to

158

EPANET 2. In CWSnet, more attention has been given to the hydraulic elements of the WDS network.

159

In addition, CWSNet provides a pressure driven model, and takes advantage of the computing power of

160

the computer’s Graphics Processing Unit (GPU). However, in CSWnet the data structures representing

161

the network are specialized to the solution methods that it uses. These data structures are not easily

162

adapted to work efficiently with the different traversal orders, and graph algorithms used by newly

163

developed solution methods. However, CWSnet still uses the same hydraulic solver and the same linear

164

solver techniques implemented in EPANET 2 (Guidolin et al. 2010).

AC C

EP

153

165

To accommodate the deficiencies referred to above, this paper presents a new hydraulic simulation

166

toolkit WDSlib. WDSlib is coded in C++, and incorporates a number of recently published techniques.

6

ACCEPTED MANUSCRIPT This toolkit offers users the ability to: (i) choose from, or modify, different approaches and implementa-

168

tions of different WDS model analyses, and (ii) extend the toolkit to include new developments. These

169

features have been implemented using fast and modularized code. A focus of attention in this research

170

has been program correctness, robustness and code efficiency. The correctness of the toolkit has been

171

validated against a reference MATLAB implementation. The differences between all results (intermedi-

172

ate and final) produced by the C++ toolkit and the MATLAB implementation were shown to be smaller

173

than 10−10 . In the interest of toolkit robustness, special attention has been paid to numerical processes

174

to guard against avoidable failures, such as loss of significance through subtractive cancellation, and nu-

175

merical errors, such as division by zero. The data structures and code libraries in WDSLib are shared and

176

all implementations have been carefully designed to ensure fairness of performance comparisons between

177

algorithms. WDSLib uses a pluggable architecture where solution-methods, and their accompanying

178

pre-processing and post-processing code are easily substituted. In addition, different numerical linear

179

algebra techniques can be incorporated using a well-defined interface. This concludes the discussion of

180

related work. The mathematical formulations of the solution methods used in WDSLib are presented in

181

the next section.

182

3 General WDS Demand-Driven Steady-State Problem

183

This section describes the general WDS demand-driven steady-state problem. The following starts with

184

the basic definitions and notation, followed by the system equations. Finally, the relevant equations are

185

shown for each of the different solution methods that are implemented in WDSLib. All variables are

186

described in the nomenclature section in Appendix E.

187

3.1 Definitions and Notation

188

Consider a water distribution system that contains np pipes, nj junctions, nr fixed head nodes and nf

189

forest pipes and nodes. The j − th pipe of the network can be characterized by its diameter Dj , length

190

Lj , resistance factor rj . The i − th node of the network has two properties: its nodal demand di and its

191

elevation zi .

SC

M AN U

TE D

EP

AC C

192

RI PT

167

Let q = (q1 , q2 , ....qnp )T denote the vector of unknown flows, h = (h1 , h2 , ....hnj )T denote the vector

193

of unknown heads, r = (r1 , r2 , ....rnp )T denote the vector of resistance factors, d = (d1 , d2 , .....dnj )T

194

denote the vector of nodal demands, el = (el1 , el2 ....elnr )T denote the vector of fixed head elevations.

195

The head loss exponent n is assumed to be dependent only on the head loss model: n = 2 for

196

the Darcy-Weisbach head loss model and n = 1.852 for Hazen-Williams head loss model. The head loss

197

within the pipe j, which connects the node i and the node k, is modelled by hi −hk = rj qj |qj |n−1 . Denote

198

by G(q) ∈ Rnp ×np , a diagonal square matrix with element [G]jj = rj |qj |n−1 for j = 1, 2, ....np . Denote

7

ACCEPTED MANUSCRIPT 199

by F (q) ∈ Rnp ×np , a diagonal square matrix where the j-th element on its diagonal [F ]jj =

200

A1 is the full rank, unknown head, node-arc incidence matrix, where [A1 ]ji is used to represent the

201

relationship between pipe j and node i; [A1 ]ji = −1 if pipe j enters node i, [A1 ]ji = 1 if pipe j leaves

202

node i, and [A1 ]ji = 0 if pipe j is not connected to node i. A2 is the fixed-head node-arc incidence matrix,

203

where [A2 ]ji is used to represent the relationship between pipe j and fixed head node i, [A2 ]ji = −1 if

204

pipe j enters fixed head node i, [A2 ]ji = 1 if pipe j leaves fixed head node i, and [A2 ]ji = 0 if pipe j is

205

not connected to fixed head node i.

206

3.2 System of Equations

207

The steady-state flows and heads in the WDS system are modeled by the demand-driven model (DDM)

208

continuity equations (1) and the energy conservation equations (2):

RI PT

SC

(1)

M AN U

−A1 T q − d = O 209

G(q)q − A1 h − A2 el = O, 210

which can be expressed as 

where its Jacobian matrix is



 F (q) J = −A1 T

214

 −A1   O

(4)

This non-linear system is normally solved by the Newton method, in which q (m+1) and h(m+1) are

EP

213

(3)

and it is sometimes referred to as a nonlinear saddle point problem (Benzi et al. 2005).

repeatedly computed from q (m) and h(m) by

AC C

212

(2)

    −A1   q  A2 el   = 0,   −  d h O

TE D

 G(q)  −A1 T 211

d dqj [G]jj qj .



F 

(m) (m)

q

−A1 T



 (m+1)

(m)



−A1   q −q  G   = − O h(m+1) − h(m) ||q (m+1) −q (m) || ||q (m+1) ||

(m) (m)

q

(m)

− A1 h



− A2 e l  , −A1 T q (m) − d

(5)

(m+1) (m) −h || are sufficiently small. and ||h (m+1) ||h ||

215

until the relative differences

216

3.3 Global Gradient Algorithm

217

Todini and Pilati (1988) applied block elimination to Eq. (5) to yield a two-step Hazen-William solver:

218

Eq. (6) for the heads and Eq. (7) for the flows.

n o h(m+1) = U −1 −nd + A1 T [(1 − n)q (m) − G−1 A2 el ] 8

(6)

ACCEPTED MANUSCRIPT 219

where U = A1 T G−1 A1

q (m+1) =

h i V h(m+1) = −d + A1 T F −1 (G − F ) q (m) − A2 el

221

222

(7)

Later, Simpson and Elhay (2010) proposed

RI PT

220

o 1n (n − 1)q (m) + G−1 (A2 el + A1 h) n

where V = A1 T F −1 A1

223

(8)

224

h i q (m+1) = q (m) + F −1 A1 h(m+1) − F −1 Gq (m) − A2 el

225

as the generalized equations that can be applied when the head-loss is modeled by the Hazen-Williams

226

equation or the Darcy-Weisbach equation. The correct Jacobian matrix with the formula for F , when

227

head loss is modeled by Darcy-Weisbach equation, can be found in Simpson and Elhay (2010). They

228

showed that the use of the correct Jacobian matrix restores the quadratic rate of convergence.

M AN U

SC

(9)

It is important to note that the GGA, as it was originally proposed, solves the entire network by a

230

non-linear solver, and this can include some unnecessary computations which can be avoided by exploiting

231

the structural properties of the WDS graph composition. The methods described below exploit these

232

structural properties to potentially improve the speed of the solution process.

233

3.4 Forest-Core Partitioning

234

Associated with a WDS is a graph G = (V, E), where the elements of V are the nodes (vertices) of the

235

graph G and elements of E are the pipes (links) of the graph G. The graph G can be partitioned into

236

smaller subgraphs with special properties. The special properties that are exploited in WDSLib and their

237

formulations are described in this subsection. The concept of partitioning the WDS network was proposed

238

by Deuerlein (2008) in order to simplify the WDS solution process. Simpson et al. (2014) extended the

239

idea of the network partitioning of Deuerlein (2008) and introduced the forest-core partitioning algorithm

240

(FCPA), which partitions the network into a treed component and a looped or core component. The

241

FCPA starts with a searching algorithm which identifies the forest subgraph, Gf = (Vf , Ef ), in which

242

S ∈ Nnf ×np is the permutation matrix which identifies the pipes in the forest, Ef , as distinct from the

243

pipes in the core , Ec , and T ∈ Nnf ×nj is the permutation matrix which identifies the nodes in the

244

forest, Vf , as distinct from the nodes in the core, Vc , as distinct from the core subgraph, Gc = (Vc , Ec ),

245

in which P ∈ Nnpc ×np is the permutation matrix for Ec and C ∈ Nnjc ×nj is the permutation matrix for

246

Vc .

AC C

EP

TE D

229

9

ACCEPTED MANUSCRIPT 247

The flows of the pipes in the forest, Sq, can be found directly from

248

 −1 Sq = − T A1 T S T T d.

249

Finally, once the iterative solution process for the core has stopped, the forest heads can be found by

250

solving a linear system:

RI PT

(10)

−1    SA2 el − SGS T Sq + SA1 C T Ch . T h = −SA1 T T

251

(11)

3.5 Reformulated Co-Tree flows method

253

A graph, with or without forest, can be partitioned into two sub-graphs: a spanning tree subgraph and

254

a complementary co-tree subgraph. The reformulated co-tree flow method (RCTM) (Elhay et al. 2014)

255

exploited the relationship between the spanning tree pipes and the co-tree pipes. The RCTM starts with

256

a spanning tree search algorithm which identifies a spanning tree subgraph, Gst = (V, Est ), in which

257

K1 ∈ Nnpst ×np is the permutation matrix that identifies the pipes in the spanning tree, Est , as distinct

258

from the pipes in the co-tree, Ect . R is the permutation matrix for the nodes which traverse the same

259

sequence as the corresponding spanning tree pipes, Est , and K2 ∈ Nnpct ×np is the permutation matrix

260

for the pipes in the complementary co-tree edges, Ect . It is important to note that there are many

261

choices of spanning tree for any cyclic graph. The choice of spanning tree and co-tree combination does

262

not affect the correctness of the method.

264

M AN U

TE D

263

SC

252

By exploiting the relationship between the spanning tree and cotree, Elhay et al. (2014) proposed

EP

(m+1)

q1

265

(m+1)

and second for the co-tree flows q2

AC C

266

(m+1)

267

268

269

270

(m+1)

the following equations to solve the WDS for the flows: first for the spanning tree flows q1

W (m+1) q 2

(m)

= L21 T q 2

b − R−T 1 d

272

273

(12)

:

    (m) (m) (m+1) (m+1) (m+1) (m) − G1 q1 + F 2 − G2 q 2 + a2 = L21 F 1

(13)

(m) (m) b b where: R1 = K1 Aˆ1 RT ; R2 = K2 Aˆ1 RT ; L21 = −R2 R−T = K1 F (m) K1 T ; F 2 = K2 F (m) K2 T 1 ; F1 (m) (m) (m) (m) b b G1 = K1 G(m) K1 T ; G2 = K2 G(m) K2 T ; W (m) = L21 (F 1 )−1 L21 T + (F 2 )−1 ; a1 = K1 Aˆ2 el ;

a2 = L21 K1 Aˆ2 el + K2 Aˆ2 el . (0)

271

,

Note that in Eq. (12), an initial set of the co-tree flows q2

is needed to commence the solution

process. The heads are found after the iterative process of the RCTM has been completed by using a linear

10

ACCEPTED MANUSCRIPT 274

solution process: (m+1)

R1 h = F 1 q 1

(m)

− (F 1 − G1 ) q 1

− a1

(14)

This partitioning of the network equations reduces the size of the non-linear component of the solver

276

to np − nj (the number of co-tree elements in the network). It has been proven by Elhay et al. (2014)

277

that the RCTM and the GGA have identical iterative results and solutions if the same starting values

278

are used. However, for the RCTM, the user only needs to set the initial flow estimates for the co-tree

279

pipes, q2 , in contrast to GGA where initial flow estimates are required for all pipes. The flows in the

280

complementary spanning pipes are generated by Eq.(12) in the RCTM.

281

4 WDSLib Structure

282

WDSLib is a WDS simulation toolkit consisting of a set of C++ member functions, which henceforth

283

will be referred to just as functions, that can be composed to solve for the steady state solution of a

284

WDS. WDSLib can be used for a once-off simulation or a multi-run simulation. Pre-packaged driver

285

code is provided to perform once-off simulations using a choice of solver methods. For a multi-simulation

286

setting, where the use-cases are very diverse, the user is able to select the desired components of WDSLib

287

to compose and compile their own driver.

M AN U

SC

(0)

RI PT

275

Individual functions in WDSLib are classified according to their role in the simulation workflow. In

289

any simulation workflow, there will be functions that will only have to be executed once. For example,

290

functions to read the input file or partition the network will only have to execute once at the start of the

291

simulation (or of all simulations). Likewise, code to reverse the network partitioning and write simulation

292

results will only have to execute once at the end of the simulation. In this work, these functions that are

293

only required to be run once are called level one (L1 ) functions. L1 functions relate to network topology,

294

which is invariant for the whole simulation. In a multi-simulation setting, certain functions will need to

295

be run once for every hydraulic-phase. An example of such a module is the module making the initial

296

guesses of pipe flow rates for the updated network configuration. In this work, these, once-per-assessment

297

functions, are called level two (L2 ) functions.

AC C

EP

TE D

288

298

Finally, for every hydraulic assessment there is a non-linear iterative phase in the solution process.

299

The functions in this phase run many times for each hydraulic assessment until the stopping test has

300

been satisfied. Examples of these include the functions to calculate the G and F matrices (see Eqs. (3)

301

and (4)) and running the Cholesky solver. These iterative-phase functions are called level three (L3 )

302

functions.

303

Fig. 1 illustrates the global structure of WDSLib under a once-off simulation setting and a multi-run

304

simulation setting. The modular setup of WDSLib allows each module to be run the minimum number

305

of times determined by its simulation setting. Under the module structure described above a once-off

11

ACCEPTED MANUSCRIPT simulation setting can be viewed as a special case where the L1 functions and L2 functions are both run

307

once. Note that after running the initial L1 functions it is possible to run hydraulic assessments of the

308

network in parallel. This mode of execution might be used in a design setting such as using a genetic

309

algorithm (GA) to optimize pipe diameter sizes.

TE D

M AN U

SC

RI PT

306

Figure 1: Global structure of WDSLib for both simulation settings

L1 and L2 functions are classified into parts a and b according to whether they run before or after

311

the lower level processing that they embed. These functions are detailed in Fig. 2. The L1 functions

312

that run at the start of the simulation are called L1a functions. These include the module (1) to read

313

the configuration file; (2) to parse the EPANET .inp file using EPANET programmer’s toolkit; (3) to

314

partition the network; and (4) to solve the linear part(s) of the network. The corresponding L1b functions

315

are run at the end of the simulation. These include tasks such as reversing the network partitioning.

316

Note that certain L1a functions require their corresponding L1b functions to be used. For example the

317

forest search module needs to be paired with the reverse FCPA permutation. There is a similar structure

318

for L2 functions. L2a functions are run at the start of each hydraulic assessment and L2b functions run

319

at the end. The functions that must be included for the FCPA method are denoted with single asterisks.

320

Likewise the functions that must be included with the RCTM method are denoted with double asterisks.

321

For these methods to work correctly all affiliated functions must be included in the simulation workflow.

322

Note that it is also possible to run both the RCTM and FCPA in the same workflow. Also note that

323

the user cannot run both GGA and RCTM in the same workflow – the user must choose between these

AC C

EP

310

12

ACCEPTED MANUSCRIPT Table 1: Key function descriptions, names, their classes, inputs and outputs. The affiliated functions are shown in sub-tables (1a) (1b) (1c) (1d). (a) Shared Modules

Module name readConfig getInputData scale AMD getRf init getGF stopTest rScale

Class Simulation Input Solver Suitesparse Solver Solver Solver Solver Solver

Input config file name EPANET .inp file void void net diameter net, resistance constant result void

(b) Global gradient algorithm (GGA)

Module name runH

Class GGASolver(Solver)

Input void

Output void

SC

Description GGA Solver

Output void EPANET err code void void resistance constant flow rate void norm void

RI PT

Description Read the configuration file Read EPANET input file Variables scaling AMD bandwidth reduction Calculate the resistance constants Generate initial guesses of flows Calculate the head loss coefficients Stopping test Recover scaled variables

(c) Forest-core algorithm (FCPA)

Module name forestSearch forestFlow forestHead rFCPA

Class topology Solver Solver Solver

Input SN, EN demands result void

M AN U

Description Forest search Calculate flows in forest Calculate heads in forest Reverse FCPA permutation

Output void flows in forest pipes heads in forest pipes void

(d) Reformulated cotree flows method (RCTM)

324

Module name STSearch runH RCTMHead rRCTM

Class topology RCTMsolver (Solver) RCTMsolver RCTMsolver

Input SN, EN void flows in ST and CT void

Output void void void void

TE D

Description Spanning tree search RCTM solver Calculate heads in ST and CT Reverse RCTM permutation

solution methods.

Table 1 provides a mapping from the function descriptions in Fig. 2 to the function names in WDSLib.

326

In addition, the dependencies between functions for each solution method are shown in Table 1a, Table

327

1b, Table 1c and Table 1d. The columns in each table list, respectively, the description of the function,

328

its name in WDSLib, the C++ class in which it appears, its input parameters, and its output values.

329

Note, that void is used in these latter two columns to denote that the function interacts with the class

330

variables rather than through its parameters and return value. Examples of how these functions can be

331

coded are presented in section 6. The key data-access functions in WDSLib are described next.

332

Getter and Setter methods

333

parameters and retrieving the results of the WDS network. These methods allow the user to reconfigure

334

the network before and during simulation runs. The names of the setter methods all start with a prefix

335

set and the names of the getter methods all start with a prefix get. For example, a user can set (write-to)

336

the diameter of pipe index to value by calling pipe->setD(index,value) and get (read-from) the head

337

of node index by calling h[index]=result->getHsol(index). A summary of the variables that can be

AC C

EP

325

Each class in WDSLib has various methods available for setting the network

13

AC C

EP

TE D

M AN U

SC

RI PT

ACCEPTED MANUSCRIPT

Figure 2: Function classification in WDSLib. The functions marked with single asterisks must be used for the FCPA method. The functions marked with double asterisks must be used for the RCTM method. Note that it is possible to use both methods at the same time.

14

ACCEPTED MANUSCRIPT Table 2: The getter and setter functions of each class and the variables they access Description Basic network properties, & Pipe and Node Node properties Pipe properties Flag information Parameter information Manage hydraulic simulation Parent class of solution methods GGA solution method RCTM solution method Network topology information Results of the simulations

Read-Access Write-Access Node,Pipe, np , nj , ns d, zs , zu SN , EN , L, D, R, pipe ID getFlag(”flagN”,flagV) setFlag(”flagN”) getPara(”paraN”,paraV) setPara(”paraN”) Result Result getCore, getForest qIter, hIter, GIter , FIter, numIter, CresIter, EresIter, Time

RI PT

Class Name Net Node Pipe Flag Parameter Simulation Solver GGASolver RCTMSolver Topology Result

read-from (read-access through getter methods) and written-to (write-access through setter methods for

339

each key classes is specified in Table 2. This concludes the discussion of the the broad structure of the

340

WDSLib package. The next section describes key aspects of the implementation of the package.

341

5 WDSLIB: Toolkit Implementation

342

This section outlines key implementation details of WDSLib. As previously mentioned, the overall aim of

343

WDSLib is to provide a clearly-structured, flexible and extensible hydraulic simulation toolkit that allows

344

testing, evaluation, and use, in production settings, of both existing and new WDS solution techniques.

345

These aims require WDSLib be implemented so that it is fast to execute, flexible to configure, robust to

346

challenging input data cases, and easy to understand and modify. The following describes aspects of the

347

implementation of WDSLib that enable it to meet these requirements. The next subsection describes the

348

general considerations that informed the design of the whole toolkit. This general discussion is followed

349

by a summary of key improvements to the solution processes encoded in forest searching and spanning

350

tree searching in the WDSLib package.

351

5.1 General capabilities and properties

352

This sub-section describes design aspects underpinning the utility and performance of WDSLib. In-

353

turn, the following outlines measures taken to: (1) maximize code clarity and modularity; (2) increase

354

the efficiency of memory access and storage; (3) maximize numerical robustness; (4) facilitate accurate

355

timing of code execution; and (5) maximize simulation speed for different settings.

356

Design Considerations 1: Modularity

357

The modular design of WDSLib is central to the evaluation and testing of different WDS solution

358

methods. All methods have been defined to perform a single, well–defined, function and each class can

AC C

EP

TE D

M AN U

SC

338

15

ACCEPTED MANUSCRIPT be compiled, used and tested independently. These features allow users to assemble the methods of

360

interest from independently developed components to create a customized WDS solution method in a

361

reliable way. WDSLib’s modular design also allows the users to profile the computation time of each

362

individual component of an algorithm. Functions communicate through well-defined interfaces and the

363

function code has been factored to minimize development and testing cost. This architecture allows

364

customized simulation applications (i) to combine the functions of interest and (ii) to implement new

365

solution algorithms to extend the functionalities of WDSLib.

366

Design Considerations 2: Memory Considerations

367

Care was taken to minimize the memory footprint of executing code (in order to reduce memory re-

368

quirements and prevent memory leaks) in the interest of the toolkit efficiency and toolkit robustness.

369

Reducing memory requirements allows the solution of larger WDS problems for a given memory ca-

370

pacity. In WDSLib, memory reduction was achieved through both, using sparse matrix representations

371

and the systematic allocation and deallocation of working structures in the C++ code. The matrices

372

used in WDS simulation are often sparse, with the density of the full node-arc incidence matrix being

373

only 2/nj . Consequently, it is more efficient to store these matrices using sparse storage schemes which

374

store only the non-zero elements of the matrix and pointers to their locations (Davis et al. 2014). It is

375

important to note that the choice of a sparse matrix representation is made based on (1) the storage

376

requirements of the matrix and (2) common search orders to column elements and row elements. This

377

latter factor means that the best format for sparse matrix representation varies with the preponderant

378

orders of search, (row-wise, column-wise, or both), employed by each method. There is a number of

379

common storage formats for sparse matrices (Compressed column storage (CCS) of Duff et al. (1989)),

380

Compressed row storage (CRS), Block Compressed column storage (BCCS), Block Compressed row stor-

381

age (BCRS), and Adjacency lists). As will be described shortly, WDSLib, uses a modified adjacency-list

382

representation.

AC C

EP

TE D

M AN U

SC

RI PT

359

383

Other implementations use a variety of storage schemes. In EPANET 2, the A1 matrix is stored

384

as two arrays of node indices, which represent start nodes (SN ) and the end nodes (EN ) of each pipe.

385

The i − th entry of the SN and EN arrays represent the start node and end node of i − th pipe of the

386

network. This storage format minimizes the memory required to store the A1 matrix because only the

387

indices are required to be stored because [A1 ](i,SNi ) = −1 and [A1 ](i,ENi ) = 1. As shown in Table 4,

388

searching through rows (pipes) of matrices that are stored in this format is efficient. However, searching

389

though the columns (nodes) is relatively inefficient. This storage format is also used in CWSnet.

390

Both CCS and CRS are used in the FCPA implementation reported in Simpson et al. (2014), and the

391

RCTM implementation reported in Elhay et al. (2014). The partial update null space method (Abraham

392

and Stoianov 2015) used CCS. The memory requirement for storing the A1 matrix in CCS is 2 × nnz +

16

ACCEPTED MANUSCRIPT 393

nj + 1 as shown in Table 4. This storage scheme is fast for searching through columns (nodes) of matrices

394

that are stored in CCS and slow for searching though rows (pipes). Table 3: The adjacency-list matrix presentation

nj

adjacent to {(vi , ej )|vi ∈ N (v1 ) ej connects v1 and vi } {(vi , ej )|vi ∈ N (v2 ) ej connects v2 and vi } {(vi , ej )|vi ∈ N (v3 ) ej connects v3 and vi } .. .

Size Deg(v1 ) Deg(v2 ) Deg(v3 ) .. .

RI PT

Node Index 1 2 3 .. .

{(vi , ej )|vi ∈ N (vnj ) ej connects vnj and vi } Deg(vnj ) Note: (1) ej is negative when vi is the start node and (2) ej is positive when vi is the end node

In WDSLib, a modified adjacency list, described in Table 3, tailored for WDS hydraulic simulation,

396

is used. An adjacency list for an undirected and unweighted graph consists of nj unordered lists for each

397

vertex ni , which contains all the vertices to which vertex ni is adjacent. The network that is shown in

398

Fig. 3 has one source, three nodes, and four pipes. The adjacency list for this network can be described

399

by four lists {{2, 3}, {1, 4}, {1, 4}, {2, 3}}. Each list describes the set of adjacent vertices of a vertex in

400

the graph. For example, the first list, {2, 3}, represents that the vertex 1 is adjacent to the vertex 2 and

401

vertex 3.

AC C

EP

TE D

M AN U

SC

395

Figure 3: A simple sample network. Numbers denote junction and pipe indices in the network.

402

The adjacency list is modified to include a directed and weighted graph for WDSLib. This mod-

403

ified adjacency list for a directed and weighted WDS graph consists of nj unordered lists for each

404

vertex ni . This list contains all the vertex and edge pairs to which vertex ni is adjacent. For ex-

405

ample, the adjacency list for the same network that is shown in Fig. 3 can be described by four lists

406

{{(2, 1), (3, −4)}, {(1, −1), (4, 2)}, {((1, 4), (4, 3)}, {(2, −2), (3, −3)}}. Each list represents the set of adja-

407

cent vertex and edge pair of a vertex in the graph. For example, the first list, {(2, 1), (3, −4)}, describes

408

that the vertex 1 is adjacent to the vertex 2 by edge 1 (from vertex 1 to vertex 2) and the vertex 3 by

409

edge 4 (from vertex 3 to vertex 1). It is fast to search through both the rows and columns of the A1 17

ACCEPTED MANUSCRIPT Table 4: Different sparse representations for A1

CCS CRS EPANET WDSlib

410

size(A1 )

size(A2 )

size([A1 A2 ])

Column Search

Row Search

2 × nnz + nj + 1 2 × nnz + np + 1 -

2 × nnz + nf + 1 2 × nnz + np + 1 -

4 × np + nn + 2 6 × np + 2 2 × np 4 × np

O(n) O((np )n) O(n) O(n)

O((nj )n) O(n) O((nj )n) O(n)

RI PT

Types

matrices that are stored in this format.

411

In addition to these optimized encodings, both G and F are diagonal square matrices, which require

412

less storage when stored as vectors than in sparse matrix form. The storage methods used for the

413

variables in WDSLib and their associated memory usage are given in Table 5.

As a final note, to offer further assurance of the correctness of memory management in WDSLib,

415

Valgrind (Nethercote and Seward 2007), a programming debugging tool, was deployed during testing to

416

detect any memory leaks, memory corruption, and double-freeing.

M AN U

SC

414

Table 5: Vectors and matrices in WDSLib type vector vector matrix matrix matrix

size np × 1 nj × 1 np × np np × nj (np − nj ) × nj

storage method vector vector vector sparse matrix sparse matrix

memory requirements np × double nj × double np × double (2 × np )× integer ≤ (np − nj ) × nj × integer

TE D

variables q, L, D, r h, d G, F A1 , A2 L21

Design Considerations 3: Numerical Considerations

418

The calculations in WDSLib are performed in C++ under IEEE-standard double precision floating point

419

arithmetic with machine epsilon mach = 2.22 × 10−16 . Invariant terms and parameters in every equation

420

were evaluated in advance and replaced by full 20-decimal digit accuracy constants. Intermediate results

421

of calculations, (which are not easily accessible in EPANET), can be output at the user’s request. The

422

stopping tolerance and stopping test can be set by the user either through the configuration file or by

423

the relevant setter method in the Parameter class.

AC C

EP

417

424

In the construction of any numerical solver, there are two primary dangers that are associated with

425

floating point arithmetic that cannot be ignored: (i) subtractive cancellation and (ii) overflow and

426

underflow. To avoid problems associated with these, all input variables are scaled to a similar range

427

to minimize the risk of avoidable computational inaccuracy or failure in floating point arithmetic. It is

428

important to note that unscaled or poorly scaled variables can unnecessarily confound a computation.

429

These scaled input variables are physically dimensionless, which allows computation which is independent

430

of the system of measurement units.

18

ACCEPTED MANUSCRIPT Table 6: WDS variables and units Variables Length Diameter Nodal head Source elevation flow demand G, F

SI unit m m m m m3 /s m3 /s s/m2

US Customary unit ft ft ft ft f t3 /s f t3 /s s/f t2

Scaling factor L0 = max (L) D0 = max (D) h0 = max (el ) el0 = max (el ) q0 = max (d) d0 = max (d) L0 n−1 G0 = D p |q0 |

RI PT

0

The variables, that are provided in EPANET input file for the package, and their corresponding units

432

in US customary and SI units are shown in Table 6. As with the input variables, the system equations

433

were modified to use dimensionless variables. Once the stopping test is satisfied, the original variables

434

are then recovered by reversing the initial scaling. Details of the scaling are shown in Appendix A.

SC

431

To help ensure that WDSLib solution methods are both fast and reliable. The sparse matrix oper-

436

ations are implemented using SuiteSparse (Davis et al. 2014). SuiteSparse is a state-of-the-art sparse

437

arithmetic suite with exceptional performance, from which the approximate minimum degree permuta-

438

tion (AMD) and the sparse Cholesky decomposition routines have been used.

439

Design Considerations 4: Timing Considerations

440

When executing WDSLib, each function reports the time spent in it by sampling wall clock time at

441

the start and end of its execution. Although the overhead for sampling wall clock time is small, there

442

are at least two special considerations involved in the interpretation of these timings: (i) the operating

443

system, at its own discretion, may launch background processes (for example anti-virus software), which

444

will distort the timings and (ii) extrapolating the timing for multiple hydraulic simulations from a single

445

analysis (as may be required, for example, in a genetic algorithm or other evolutionary algorithm run)

446

must be done with care because the relationship between the different settings is not linear.

EP

TE D

M AN U

435

This concludes the discussion of the main considerations concerning the global design of WDSLib. In

448

the following, key details of the implementation of selected parts of the solution processes are described.

449

5.2 Key Improvements to Solution Processes

450

The WDSLib implementation makes several improvements to extant solution processes. This section

451

focuses on the improvement of the network partitioning processes in FCPA and RCTM.

452

Key Optimization 1: Improvements to partitioning in Forest Search

453

The forest-core partitioning algorithm (FCPA) in this paper is a substantial improvement over the

454

algorithm of the original paper (Simpson et al. 2014). Specifically the original FCPA algorithm almost

455

always required many sweeps of the columns (nodes) of the A1 matrix in order to reduce the forest

AC C

447

19

ACCEPTED MANUSCRIPT 456

component down to the core component. The refined algorithm exploits the adjacency list representation

457

of the A1 matrix so that the partitioning process is achieved in a single sweep. This improves the speed

458

of the partitioning process from being O(anp ) to O(np + nf ) where a is the depth of the deepest tree-

459

component in the forest. This can lead to substantial time savings in the case when a is relatively

460

large. The pseudo-code for this refined forest search algorithm is shown in Appendix B This algorithm

462

traverses each tree component in turn from its leaf nodes, which maximizes the locality of operations

463

with respect to the graph representation. In this algorithm, a node is identified as a leaf node when

464

its node degree is one. Every time a leaf node, node k, is identified, the node pointer is moved to its

465

adjacent node, node k, and the node degree of node k is reduced by one. This process repeats if the

466

adjusted node degree of node k is one. Otherwise, node k is the root node for this tree and the algorithm

467

progresses to the next tree in the forest.

468

Key Optimization 2: Improvements to Spanning Tree Search

469

The reformulated co-tree flows method (RCTM) in this paper is also a substantial improvement over

470

the algorithm of the original paper (Elhay et al. 2014). The original spanning tree search algorithm

471

sweeps the rows of the A1 matrix (pipes) in order to identify the singleton rows and their corresponding

472

columns. The spanning tree search in the original RCTM required a sweep of the A1 matrix to identify

473

the next pipe in the spanning tree. This algorithm is O(np nj ), which is relatively inefficient.

TE D

M AN U

SC

RI PT

461

The pseudo-code for the refined spanning tree/forest search algorithm is shown in Appendix C. This

475

improved algorithm takes as input the adjacency list describing the network and the pipe indexes of

476

the core component of the network from the Algorithm 1 (if the FCPA is used). In this algorithm, all

477

water sources are the starting point of the search process, SN , and marked as visited. The nodes in SN

478

are then used as to identify a spanning tree within the WDS. This is achieved by repeatedly finding all

479

adjacent pairs, node t and pipe s, of and removing the first node in SN by using the adjacency list. If

480

the adjacent node t is not visited then node t is inserted into the spanning-tree node vector, ST N , and

481

search node vector, SN , and node t is marked as visited and pipe s to the spanning-tree pipe vector,

482

ST P , and pipe s is marked as visited. If the adjacent node t is visited and the pipe s is not visited

483

then the pipe s is inserted into the co-tree pipe vector, CT P and mark pipe s as visited. This process

484

is repeated until SN is empty. The overall time-complexity of this algorithm is O(np + nj ) (compared

485

to O(np nj ) as mentioned above) is the same as the best asymptotic complexity of breadth-first search

486

on a graph.

AC C

EP

474

20

ACCEPTED MANUSCRIPT

6 Example Applications

488

WDSLib consists of a collection of functions which can be used either as a standalone application for fast

489

one-off simulations or as a library of software components that can be integrated into a user’s own WDS

490

solution processes. This section presents two example applications. The first application is the setup for

491

a basic one-off simulation of a WDS. The second application (described in subsection 6.1) presents an

492

example using WDSLib to implement a simple 1+1 Evolutionary Strategy (Beyer and Schwefel 2002)

493

(1+1-ES or, more commonly, 1+1EA) for sizing pipes in a WDS.

494

Example 1 - Once-off Simulation

495

The setup for WDSLib as a standalone application is straightforward. The user provides a configuration

496

text file that specifies input and output filenames; the name of the solver; the desired output variables;

497

and simulation parameters. These values have sensible defaults so the user can set up the solver by using

498

a minimal configuration such as that shown in Fig. 4. By using this config file, WDSLib is configured to

499

run a single hydraulic analysis of the network that is stored as say ”hanoi.inp”, an EPANET- formatted

500

input file, under ”Network/” sub-directory, using the reformulated co-tree flows method with the forest-

M AN U

SC

RI PT

487

core partitioning algorithm. The full set of configuration parameters for once off simulations is shown in

EP

TE D

[ InputFile ] < directory > % the input file d i r e c t o r y Network / < file > % the input file name hanoi . inp % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -% [ controlFlag ] < SolverFlag > % 1 for GGA 2 for RCTM 2 < FCPAFlag > 1 % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -%

AC C

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Figure 4: A minimal configuration file to run the GGA in WDSLib

501

502

Fig. 11 in Appendix D.

503

6.1 Example 2 - A Simple Network Design Application

504

As a minimalist example of the application of WDSLib to a WDS network design problem, the following

505

example uses 1+1EA for optimally sizing pipe diameters. This algorithm takes an existing network

506

with randomly generated pipe diameters and optimizes the network to minimize cost, subject to given

507

pressure head constraints. A 1+1EA is a very simple evolutionary strategy (Beyer and Schwefel 2002)

508

which starts with a randomly generated individual (in this case a WDS diameter configuration). This

21

ACCEPTED MANUSCRIPT

M AN U

SC

RI PT

# include " Simulation . h " # include " result . h " using namespace std ; # define GTN 100000 // the total number of g e n e r a t i o n s /* a v a i l a b l e pipe d i a m e t e r s ( inches ) */ vector < int > ADiameter ={36 ,48 ,60 ,72 ,84 ,96 ,108 ,120 ,132 ,144 ,156 ,168 ,180 ,192 ,204}; /* dollar per unit length */ vector < int > unitCost ={93.6 ,133.7 ,176.3 ,221 ,267.6 ,315.8 ,365.4 ,416.5 ,468.7 , 522.1 ,576.6 ,632.1 ,688.5 ,745.1 ,804.1}; vector < int > g e n e r a t e i n i t i a l D i a m e t e r s ( int ) ; // see fig . 6 vector < int > mutate ( vector < int >) ; // see fig . 7 double evaluate ( Net * , Result *) ; // see fig . 8 int main ( int argc , char * argv []) { srand (1) ; char * config = argv [1]; Result * result = new Result () ; Simulation * simulation1 = new Simulation () ; // i n i t i a l i z e the s i m u l a t i o n class Net * net = simulation1 - > L1a ( result , config ) ; // perform the L1a f u n c t i o n s vector < int > p1 = g e n e r a t e i n i t i a l D i a m e t e r ( net - > getNp () ) ; // initial guesses of d i a m e t e r vector < int > p2 ; // work space for current best double cost , currentbest ; for ( int i =0; i < GTN ; i ++) { simulation1 - > setD (& p1 ,& ADiameter , net - > getPIPE () -> Diascale () ) ; simulation1 - > solve ( result ) ; // perform the L2 and L3 f u n c t i o n s simulation1 - > L1b ( result ) ; // reverse the p e r m u t a t i o n cost = evaluate ( result , net ,& p1 ) ; // e v a l u a t e the network cost if ( cost < currentbest || i ==0) { // s e l e c t i o n o p e r a t o r currentbest = cost ; p2 = p1 ; cout < dispResult ( result ) ; delete simulation1 ; delete result ; return 0; }

TE D

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Figure 5: Example code for 1+1EA for Pipe Sizing 1+1EA then progresses by applying a mutation to a random pipe diameter size, and then evaluating the

510

new individual. If the new individual is better it replaces the old network. This process continues in a

511

loop until a given number of evaluations is reached.

513

514

515

516

517

The C++ code for this example is shown in Figs. 5, 6, 7, and 8. If the name of the file containing this code is: simpEA.cc then the simplest command to compile this code is:

AC C

512

EP

509

g++ simpEA.cc -o simpEA -Llib -lWDSLib To run this code the user would type: ./simpEA config.txt where config.txt contains the same configuration text as for the previous example.

518

Starting with the main function in Fig. 5, line 15 points to the config file specified by the command

519

line. The next two lines initialize the result and the simulation according to the configuration file.

520

This is followed by the L1a module to perform the user selected L1a functions. Line 19 generates the

521

initial pipe diameters of the network and line 20 initializes the workspace for the mutated string. Line 22

ACCEPTED MANUSCRIPT

vector < int > g e n e r a t e i n i t i a l D i a m e t e r s ( int np ) { vector < int > Diameter = vector < int >( np ) ; for ( int i =0; i < np ; i ++) Diameter [ i ]= rand () % ADiameter . size () ; // set the index for pipe d i a m e t e r s return Diameter ; }

RI PT

1 2 3 4 5 6 7

vector < int > mutate ( vector < int >* string ) { vector < int > string1 ; string1 =* string ; int aa = rand () %( string - > size () ) ; // choose which pipe to mutate int a = rand () % ADiameter . size () ; // choose a pipe d i a m e t e r after the m u t a t i o n ( string1 ) [ aa ]= a ; // set the pipe index return string1 ; }

M AN U

1 2 3 4 5 6 7 8

SC

Figure 6: Implementation code for pipe size initialization

double evaluate ( Result * result , Net * net , vector < int > * p1 ) { PIPE * pipe = net - > getPIPE () ; double np = net - > getNp () ; double nj = net - > getNj () ; double P =1 e7 ; double cost1 =0; penaltyCost =0; vector < double > hsol = result - > getHsol () ; // get the vector of nodal heads vector < double >* L = pipe - > getL () ; // get the vector of pipe lengths vector < double >* zu = net - > getNODE () -> getZU () ; // get the vector of nodal e l e v a t i o n s double Lscale = pipe - > Lenscale () ; // get the scaling factor for length for ( int i = 0; i < np ; i ++) cost1 +=(* L ) [ i ]* Lscale * unitCost [(* p1 ) [ i ]]; // c a l c u l a t e the m a t e r i a l cost for ( int i = 0; i < nj ; i ++) if (( hsol ) [ i ] -(* zu ) [ i ] < minP ) penaltyCost +=( minP -( hsol ) [ i ]+(* zu ) [ i ]) * scaleP ; // c a l c u l a t e penalty cost return cost1 + penaltyCost ; }

AC C

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

EP

TE D

Figure 7: Implementation code for the mutation operator

Figure 8: Implementation code for the evaluation function

23

ACCEPTED MANUSCRIPT 23 sets the pipe diameters of the network. Line 24 evaluates the current network configuration. The

523

permutation and scaling for the current individual is reversed by L1b in line 25 of Fig. 5. Line 26

524

calculates the fitness of the current network configuration by using the evaluate function in Fig. 8. This

525

function applies a penalty for pressure head constraint violations and pipe material costs. The body

526

of the 1+1EA is contained in the selection operator and mutation operator that follow. Lines 27 to 31

527

compare the string in the current generation with the current best string if the individual p1, as measured

528

by evaluate is better than the individual p2 then p1 replaces p2. Line 32 mutates the current network,

529

p2, using mutate (see Fig. 7). The mutate function changes the diameter of a randomly selected pipe in

530

the network to a randomly selected diameter, chosen from a set of commercially available pipe diameters.

531

The mutated individual, stored in the workplace p1, is used as the network configuration for the next

532

iteration. Until the total number of generations is reached, the user selected information about the best

533

individual is outputted by dispResult in line 34 of Fig. 5.

SC

RI PT

522

It should be noted that the algorithm described above can be used to design a simple WDS but is

535

not optimal in terms of speed of convergence. Other EA’s such as genetic algorithms (Simpson et al.

536

1994) will perform better. However the above example has the advantage of simplicity and contains all

537

the basic elements that a GA would use when interacting with WDSLib.

538

M AN U

534

This concludes the presentation of examples in this work. The next section presents a case study that illustrates the performance of WDSLib in a multi-simulation setting.

540

7 Case Study

541

The following presents timing results for WDSLib running the 1+1EA described in the previous section.

542

The results below compare the four different solvers plus EPANET2. Note, that detailed timings for

543

once-off simulations comparing the four methods can be found in Qiu et al. (2018). Three networks

544

were benchmarked in these experiments. These were the N1 , N3 , and N4 case-study networks used in

EP

TE D

539

AC C

Simpson et al. (2014). Table 7 summarizes the characteristics of these networks.

Network N1 N3 N4

Full np 934 1975 2465

Table 7: Benchmark networks summary Network nj ns 848 8 1770 4 1890 3

Forest & Core Networks nf (nf /n# njc n pc p ) 361 (38%) 573 487 823 (42%) 1152 947 429 (17%) 2036 1461

Co-tree Network nct 84 205 757

545

546

Table 8 shows the results of the 1+1EA from Fig. 5 for the GGA, GGA with FCPA, RCTM, RCTM

547

with FCPA and the EPANET2 solvers. For each of the four WDSLib solvers above, the timings are

548

given for running the EA with and without the L1 modules hoisted out the main EA loop. Each

24

ACCEPTED MANUSCRIPT 549

experiment evaluates the WDS network 100,000 times. And the best performing method for each network

550

is highlighted in bold. It is important to note that 1+1EA using both the GGA and the WDSLib Table 8: The actual 1+1EA run-time with 100,000 evaluations (min.) for each of the four solution methods applied networks N1 , N3 , N4 GGA with FCPA min. 4.64 9.79 16.29

RCTM min. 4.53 13.75 23.92

RCTM with FCPA min. 4.13 10.30 21.93

EPANET min. 9.81 26.43 67.11

RI PT

N1 N3 N4

GGA min. 6.73 15.21 21.14

The results show that the EA runs using WDSLib are substantially faster than the runs using the

552

EPANET2 solver. This is, in part, due to the fact that the EPANET2 solver is designed as a standalone

553

solver which does not facilitate lifting out of invariant computations from the EA loop.

SC

551

As a demonstration of how the performance of an EA can be traced Fig. 9 shows the evolution of the

555

fitness values of the N1 network. These traces were extracted from a file written to in line 30 in Fig. 5.

556

As can be seen, the cost and the pressure head violation terms drop during the EA run. Note that there

M AN U

554

will be considerable variation between 1+1EA runs due to its highly stochastic nature.

3.4

10 8

TE D

3.2

3

Cost

2.8

2 10 0

AC C

2.2

EP

2.6

2.4

Total Cost Pressure Violation Penalty

10 1

10 2

10 3

10 4

10 5

Number of evaluations

Figure 9: The evaluation of the fitness value of network N1 557

558

8 Conclusions

559

This paper has described WDSLib, a library for steady-state hydraulic simulation of WDS networks.

560

WDSLib is fast, modular, and portable with implementation of several standard and recently published 25

ACCEPTED MANUSCRIPT hydraulic solution methods. We have outlined the supported solution methodologies, the structure of the

562

package and key aspects of WDSLib’s implementation. Two example applications have been presented

563

including a design case study using a simple EA. The EA results were benchmarked for different solvers

564

demonstrating a substantial improvement in speed over the industry standard EPANET2 package. These

565

benchmarks also have illustrated how the modular structure of WDSLib could be exploited to speed up

566

execution time in a design setting.

RI PT

561

As well as providing a fast simulation platform for both once-off and multi-run simulations, WD-

568

SLib also provides a testbed for comparing different solution methods in different settings and network

569

topologies. As such WDSLib is designed with a pluggable architecture which can extended to efficiently

570

incorporate new solution methods as they are created. This will enhance the capability of the research

571

community to demonstrate the efficacy of new methods without having to re-engineer the content of

572

shared WDSLib functions and data representations.

SC

567

WDSLib accepts the input file format used by EPANET2 which allows for simple deployment. The

574

amount of coding required to use the provided solvers in WDSLib is minimized by the use of a simple

575

and extensible configuration file.

M AN U

573

WDSLib is currently limited to finding solutions of demand-driven WDS systems without control

577

devices. The development of software components to simulate control devices and pressure driven models

578

is future work.

579

References

580

Abraham, E. and I. Stoianov (2015). “Sparse null space algorithms for hydraulic analysis of large-scale

581

water supply networks”. Journal of Hydraulic Engineering, p. 04015058. doi: 10.1061/(ASCE)HY.

582

1943-7900.0001089.

584

585

586

EP

Benzi, M., G. H. Golub, and J. Liesen (2005). “Numerical solution of saddle point problems”. Acta Numerica 14, pp. 1–137. doi: 10.1017/S0962492904000212.

AC C

583

TE D

576

Beyer, H. G. and H. P. Schwefel (2002). “Evolution strategies–A comprehensive introduction”. Natural Computing 1.(1), pp. 3–52. doi: 10.1023/A:1015059928466.

587

Cheung, P. B., J. E. Van Zyl, and L. F. R. Reis (2005). “Extension of EPANET for pressure driven

588

demand modeling in water distribution system”. Computing and Control for the Water Industry 1,

589

pp. 311–316.

590

591

592

Cross, H. (1936). “Analysis of flow in networks of conduits or conductors”. University of Illinois. Engineering Experiment Station. Bulletin; no. 286. Davis, Tim, WW Hager, and IS Duff (2014). “SuiteSparse”. http://faculty.cse.tamu.edu/davis/suitesparse.html.

26

ACCEPTED MANUSCRIPT 593

594

Deuerlein, J. W. (2008). “Decomposition model of a general water supply network graph”. Journal of Hydraulic Engineering 134.(6), pp. 822–832. doi: 10.1061/(ASCE)0733-9429(2008)134:6(822).

595

Deuerlein, J. W., S. Elhay, and A. R. Simpson (2015). “Fast Graph Matrix Partitioning Algorithm

596

for Solving the Water Distribution System Equations”. Journal of Water Resources Planning and

597

Management 142.(1), pp. 04015037-1–04015037-11. Diao, Kegong, Zhengji Wang, Gregor Burger, Chien-Hsun Chen, Wolfgang Rauch, and Yuwen Zhou

599

(2014). “Speedup of water distribution simulation by domain decomposition”. Environmental Mod-

600

elling & Software 52, pp. 253–263. issn: 1364-8152. doi: https://doi.org/10.1016/j.envsoft.

601

2013.09.025. url: http://www.sciencedirect.com/science/article/pii/S1364815213002247.

602

Duff, I. S., R. G. Grimes, and J. G. Lewis (1989). “Sparse matrix test problems”. ACM Transactions on Mathematical Software (TOMS) 15.(1), pp. 1–14.

SC

603

RI PT

598

Elhay, S. and A. R. Simpson (2011). “Dealing with zero flows in solving the nonlinear equations for

605

water distribution systems”. Journal of Hydraulic Engineering 137.(10), pp. 1216–1224. doi: 10 .

606

1061/(ASCE)WR.1943-5452.0000561.

M AN U

604

607

Elhay, S., A. R. Simpson, J. Deuerlein, B. Alexander, and W. H. Schilders (2014). “Reformulated co-

608

tree flows method competitive with the global gradient algorithm for solving water distribution sys-

609

tem equations”. Journal of Water Resources Planning and Management 140.(12), pp. 04014040-1–

610

04014040-10. doi: 10.1061/(ASCE)WR.1943-5452.0000431.

612

Epp, R. and A. G. Fowler (1970). “Efficient code for steady-state flows in networks”. Journal of the

TE D

611

Hydraulics Division 96.(1), pp. 43–56.

Estrada, Carlos, C´esar Gonz´ alez, Ricardo Aliod, and Jara Pa˜ no (2009). “Improved pressurized pipe

614

network hydraulic solver for applications in irrigation systems”. Journal of irrigation and drainage

615

engineering 135.(4), pp. 421–430.

EP

613

Gorev, N. B., I. F. Kodzhespirov, Y. Kovalenko, E. Prokhorov, and G. Trapaga (2012). “Method to Cope

617

with Zero Flows in Newton Solvers for Water Distribution Systems”. Journal of hydraulic engineering

618

139.(4), pp. 456–459. doi: 10.1061/(ASCE)HY.1943-7900.0000694.

AC C

616

619

Guidolin, M., P. Burovskiy, Z. Kapelan, and D. A. Savic (2010). “CWSNet: An object-oriented toolkit for

620

water distribution system simulations”. Proceedings of the 12th Annual Water Distribution Systems

621

Analysis Conference, WDSA, pp. 12–15.

622

Jun, L. and Y. Guoping (2012). “Iterative methodology of pressure-dependent demand based on EPANET

623

for pressure-deficient water distribution analysis”. Journal of Water Resources Planning and Man-

624

agement 139.(1), pp. 34–44. doi: 10.1061/(ASCE)WR.1943-5452.0000227.

625

Morley, M. S., R. M. Atkinson, D. A. Savic, and G. A. Walters (2000). “OpenNet: An applicationin-

626

dependent framework for hydraulic network representation, manipulation, and dissemination”. Hy-

627

droinformatics 2000 Conference, University of Iowa, Iowa City, USA, pp. 23–27.

27

ACCEPTED MANUSCRIPT 628

629

630

631

Morley, M. S. and C. Tricarico (2008). Pressure-Driven Demand Extension for EPANET (EPANETpdd). Tech. rep. University of Exeter. Nethercote, N. and J. Seward (2007). “Valgrind: a framework for heavyweight dynamic binary instrumentation”. ACM Sigplan notices. Vol. 42. 6. ACM, pp. 89–100. doi: 10.1145/1273442.1250746. Perelman, Lina and Avi Ostfeld (2011). “Topological clustering for water distribution systems analysis”.

633

Environmental Modelling & Software 26.(7), pp. 969–972. issn: 1364-8152. doi: https://doi.org/

634

10.1016/j.envsoft.2011.01.006. url: http://www.sciencedirect.com/science/article/

635

pii/S1364815211000259.

RI PT

632

Qiu, M., S. Elhay, A. R. Simpson, and B. Alexander (2018). “A Benchmarking Study of Water Distribu-

637

tion System Solution Methods”. Manuscript accepted for publication to Journal of Water Resources

638

Planning and Management.

640

Rahal, H. (1995). “A co-tree flows formulation for steady state in water distribution networks”. Advances in Engineering Software 22.(3), pp. 169–178. doi: 10.1016/0965-9978(95)00020-W.

M AN U

639

SC

636

641

Rossman, L. A. (2000). “Epanet 2 users manual, us environmental protection agency”. Water Supply and

642

Water Resources Division, National Risk Management Research Laboratory, Cincinnati, OH 45268.

643

Schilders, W. H. (2009). “Solution of indefinite linear systems using an LQ decomposition for the linear

644

constraints”. Linear Algebra and its Applications 431.(3), pp. 381–395. doi: 10.1016/j.laa.2009.

645

02.036.

647

Siew, C. and T. T. Tanyimboh (2012). “Pressure-dependent EPANET extension”. Water resources man-

TE D

646

agement 26.(6), pp. 1477–1498. doi: 10.1061/41203(425)9. Simpson, A. R., G. C. Dandy, and L. J. Murphy (1994). “Genetic algorithms compared to other tech-

649

niques for pipe optimization”. Journal of water resources planning and management 120.(4), pp. 423–

650

443. doi: 10.1061/(ASCE)0733-9496(1994)120:4(423).

EP

648

Simpson, A. R. and S. Elhay (2010). “Jacobian matrix for solving water distribution system equations

652

with the Darcy-Weisbach head-loss model”. Journal of hydraulic engineering 137.(6), pp. 696–700.

653

doi: 10.1061/(ASCE)HY.1943-7900.0000341.

AC C

651

654

Simpson, A. R., S. Elhay, and B. Alexander (2014). “Forest-Core Partitioning Algorithm for Speeding

655

Up Analysis of Water Distribution Systems”. Journal of Water Resources Planning and Management

656

140.(4), pp. 435–443. doi: 10.1061/(ASCE)WR.1943-5452.0000336.

657

Todini, E. and S. Pilati (1988). “A gradient algorithm for the analysis of pipe networks”. Computer

658

applications in water supply: vol. 1—systems analysis and simulation. Research Studies Press Ltd.,

659

pp. 1–20.

660

Vassiljev, A. and T. Koppel (2015). “Estimation of real-time demands on the basis of pressure mea-

661

surements by different optimization methods”. Advances in Engineering Software 80, pp. 67–71. doi:

662

10.1016/j.advengsoft.2014.09.023.

28

ACCEPTED MANUSCRIPT

TE D

M AN U

SC

RI PT

EPANET”. Advances in Water Supply Management (CCWI 2003).

EP

664

van Zyl, J. E., J. Borthwick, and A. Hardy (2003). “Ooten: An object-oriented programmers toolkit for

AC C

663

29

ACCEPTED MANUSCRIPT 665

Appendix A Scaling

666

In WDSlib, all input variables are scaled to a similar range to minimize the risk of avoidable computa-

667

tional inaccuracy or failures in floating point arithmetic. ˆ = h/h0 , eˆl = el /el0 , d ˆ = d/d0 where ˆ = G/G0 , q ˆ = q/q0 , h The variables are scaled as following: G

669

ˆ eˆl , ˆ h, G, h, el , and d are the original input vectors, G0 , h0 , el0 , and d0 are the scaling factors and G,

670

and dˆ are the scaled input vectors.

671

RI PT

668

ˆ 0 , el = eˆl el0 , d = dd ˆ 0 , Eq. (1) and Eq. (2) become: ˆ 0, q = q ˆ q0 , h = hh By substituting G = GG

ˆ − el0 A2 eˆl = 0 ˆ q − h0 A1 h G0 q0 Gˆ

673

ˆ=0 ˆ − d0 d q 0 A1 T q

674

Eq. (15) and Eq. (16) can be further simplified by introducing the notation: a = h0 / (G0 ∗ q0 ), b =

675

el0 / (G0 ∗ q0 ), and c = d0 /q0 :

M AN U

676 677

678

679

with the following matrix form: 

680

683

A1 T qˆ − cdˆ = 0

(18)









ˆ   bA2 eˆl  −A1   q  −  = 0. ˆ ˆ O ah cd

(19)

Finally, the network can be solved by using Eq. (20) and Eq. (21): ˆ − A1 F ˆ (m+1) = 1 U −1 [−cd ˆ −1 [(F ˆ − G)ˆ ˆ q (m) + bA2 eˆl ]] h a

(20)

ˆ m+1 − F ˆ −1 A1 h ˆ −1 (Gˆ ˆ q (m) − bA2 eˆl ) ˆ (m+1) = q ˆ (m) + aF q

(21)

EP

682

(16)

(17)

AC C

681

(15)

ˆ − bA2 eˆl = 0 ˆ q − aA1 h Gˆ

TE D

ˆ  G  −A1 T

SC

672

684

Choice of scaling factors

685

The choice of the scaling factor, despite much research, is not well understood. In this subsection, a

686

choice for each scaling factor, based on the experience of the authors, is recommended. There are two

687

types of variables and parameters that need to be scaled: invariants and variants.

688

Data sets that have very wide range of values can confound numerical accuracy. As a result, it may

689

be preferable to scale the data to a narrower range. The default scaling factor for each of the input data

690

is chosen to be its maximum absolute value. For example, the scaling factor for demand is max(d), so

691

that its values range from zero to one.

692

In contrast, it is more difficult to choose a scaling factor a priori for values that vary between iterations 30

ACCEPTED MANUSCRIPT 693

(variants). This is because the range of variants can change as the iteration progresses. As a result, the

694

intermediate and the final results might not be within the same range as the initial guesses.

698

connected to a water source and a good choice of the scaling factor for nodal head is max(el ) because

699

the maximum nodal head cannot exceed the maximum elevation head of the fixed nodes.

696

RI PT

697

There are two variants that need to be scaled: q, h. A good choice of the scaling factor for the P d flow rate is because the demand at each node must be satisfied by the water sources in the WDS nf and it is a reasonable assumption that the all demands are equally carried by each pipe that is directly

695

700

During the process of the computation, the matrices G and F are scaled because their input variables

701

are scaled. For the Darcy-Weisbach head loss model, the diagonal elements of the matrix G are modelled

702

by: [G]jj = diag

703

where the friction factor f is modelled by the Swamee-Jain formula:

M AN U

704

) 8 Lj ( 2 ) 5 fj |qj | for j = 1, . . . , np π g Dj

SC

(

 64      Re   j fj = P3 (α + β /θ )(Re /2000)k k k j j  k=0       0.25

705

log2 (θj )

709

710

711

712

713

if Rej ≥ 4000

TE D

708

(22)

In order to make sure the Reynolds number, a dimensionless variable, is not affected by scaling, D0 4ˆ qj q0 ν ˆ= ν is introduced, Reynolds number Rej becomes , which can be further simplified ˆ j D0 q0 πˆ ν (q0 /D0 )D 4ˆ qj to , where the scaling factors are canceled. ˆj πˆ νD In order to make sure f is also not affected by the scaling, ˆ = D0  is introduced, θj becomes

EP

707

if 2000 < Rei < 4000

5.74 4qj j + and Rej = for j = 1, . . . , np . Note that αk and βk are constant, the 3.7Dj πνD Re0.9 j j values of which can be found in Elhay and Simpson (2011) where θj =

AC C

706

if Rej ≤ 2000

θj =

ˆj D0 5.74 + for j = 1, . . . , np ˆ Re0.9 3.7Dj D0 j

which can be further simplified to

714

θj =

ˆj ˆj 3.7D

+

5.74 for j = 1, . . . , np Re0.9 j

715

where the scaling factors are canceled. It is evident that the friction factors remain the same because

716

the values for the only two variables Re and θ are unchanged.

717

718

ˆ where G0 = ( 8 ) L0 |q0 | and [G] ˆ jj = Finally, diagonal elements of G can be expressed as: G0 G, π 2 g D05 ( ) ˆj L diag f |ˆ q | for j = 1, . . . , np . ˆ5 j j D j

31

ACCEPTED MANUSCRIPT

721

For the Hazen-Williams head loss ) model, the diagonal elements of the matrix G are modelled by: ( 10.67Lj |qj |(n−1) for j = 1, . . . , np , where Cj is the Hazen-Williams coefficient for [G]jj = diag Cj1.852 Dj4.871 the j-th pipe. The Hazen-Williams coefficient, unlike the friction factor in the Darcy-Weisbach head

722

loss model, is independent of flow rate, pipe wall condition, and flow regimes, which means it is an

720

723

724

725

726

independent ( variable. As a result, the scaling factor for)Hazen-Williams G can simply be derived by: ˆ j L0 10.67L [G]jj = diag |ˆ q |(n−1) |q0 |(n−1) and the equation for diagonal elements of G 1.852 1.852 ˆ 4.871 D4.871 j ˆ C0 D Cj 0 j n o ˆ , where G0 = 10.67L0 |q0 |(n−1) for Hazen-Williams equation can be expressed as: G = diag G0 G C01.852 D04.871 ) ( ˆ Lj |ˆ q |(n−1) for j = 1, . . . , np . and [G]jj = diag 1.852 ˆ 4.871 j ˆ D C j

RI PT

719

j

Why scaling should be applied

728

Case 1 from Estrada et al. (2009) is used here to demonstrate the efficacy of using scaled variables. The

729

layout of the Case 1 from Estrada et al. (2009) is given in Fig. 10. Details of the pipe and node values

730

are given in Table 9 and Table 10.

TE D

M AN U

SC

727

EP

Figure 10: The layout of the Case 1 from Estrada et al. (2009)

Table 9: The nodal values of the Case 1 from Estrada et al. (2009)

AC C

Node ID Reservoir A Reservoir B Junc C Junc D

Elevation (m) 10 10 0 0

Demand (LPS) 2.7 0

Table 10: The pipe values of the Case 1 from Estrada et al. (2009)

Pipe ID Pipe 1 Pipe 2 Pipe 3 Pipe 4

731

Start Node Reservoir A Reservoir B Junc D Reservoir A

End Node Junc C Junc C Junc C Junc D

Length (m) 0.25 0.5 100 100

Diameter (mm) 1200 1200 1200 1200

Running this example network from EPANET and WDSLib, we get the following results:

32

ACCEPTED MANUSCRIPT Table 11: The nodal heads found by using EPANET and WDSLib

Node ID Junc C Junc D

EPANET WDSLib Head (m) 10 10 10 10

M AN U

735

In contrast, the energy residual and the continuity residual of the WDSLib result are 1.8723 × 10−12 and 1.7849 × 10−9 respectively which are both acceptable.

TE D

734

respectively. These two residuals are too large which indicates an inaccurate solution.

EP

733

The energy residual and the continuity residual of the EPANET result are 2.6973 and 5.3575 × 10−4

AC C

732

EPANET WDSLib Flow (LPS) 1.3446 1.5924 1.3446 1.5924 0.0108 0.0124 0.0108 0.0124

SC

Link ID Pipe 1 Pipe 2 Pipe 3 Pipe 4

RI PT

Table 12: The flows found by using EPANET and WDSLib

33

ACCEPTED MANUSCRIPT

Appendix B Forest Search Algorithm

EP

TE D

SC

M AN U

k ← 1; for i ← 1 to nj do n = i; while Deg(n) == 1 do for (Adjp ,Adjv ) ∈ Adj(n) do if Deg(Adjv ) == 1 then F orest[k] ←Union(F orest[k], (Adjp , n)) else q(Adjp ) ← d(n); d(Adjv ) ← d(Adjv ) + d(n); Deg(Adjv ) ← Deg(Adjv ) − 1; n = Adjv ; if Deg[n] ≥ 2 then RootN ode[k] = n; k ← k + 1; end if end if end for end while end for

RI PT

Algorithm 1: Forest Search Algorithm input : Adjacency list, d and Deg output: Forest, RootNode, q and d

AC C

736

34

ACCEPTED MANUSCRIPT

Appendix C Spanning Tree Search Algorithm

SC

// mark the source i as visited this node into the search node vector

// mark pipe as a spanning tree pipe as a corresponding spanning tree pipe

EP

TE D

M AN U

for i ← nj to nf do V N [i] = true ; SN ← i ; // insert end for while SN is not empty do i ← the first element in SN ; foreach (Adjp ,Adjv ) ∈ Adj[i] do if VN[Adjv ] == false then ST P ← Adjp ; ST N ← Adjv ; // mark node SN ← Adjv ; VN[Adjv ]=true; VP=[Adjp ]=true; end if else if VN[Adjp ]==false then CT P ← Adjp ; VP[Adjp ]=true; end if end foreach remove i from SN ; end while

35

pipes nodes pipes nodes pipes nodes

RI PT

Algorithm 2: Spanning Tree Search Algorithm input : adjList output: Spanning Tree and Co-Tree elements ST P ← {} ; // initialize an empty vector for spanning tree ST N ← {} ; // initialize an empty vector for spanning tree CT P ← {} ; // initialize an empty vector for co-tree V N ← {} ; // initialize a boolean vector for visited V P ← {} ; // initialize a boolean vector for visited SN ← {} ; // initialize an empty set of searching

AC C

737

// removed pipe j as a singleton pipe

ACCEPTED MANUSCRIPT

Appendix D Complete configuration files

M AN U

SC

RI PT

[ InputFile ] < directory > % R E Q U I R E D I N F O R M A T I O N the input file d i r e c t o r y WDSnetwork / < file > % R E Q U I R E D I N F O R M A T I O N the input file name n1 . inp % end of input file % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -% [ Parameter ] < maxIter > % maximum number of i t e r a t i o n 50 < initV > % initial veloc ity 0.3048 % 1 ft / s < StopTol > % s t o p p i n g t o l e r a n c e used 1.000 e -6 < NormTyp > % norm type 1 for 1 - norm , 2 for 2 - norm , 3 for inf - norm 3.0 < StopTest > % s t o p p i n g test used 1 for q - norm , 2 for h - norm 3 for q &h - norm 1 < SerP > % service p r e s s u r e 20.0 < MinP > % Minimum p r e s s u r e 40.0 < Demandfuc > % type of c o n s u m p t i o n fu nc t i o n 1.00 < MaxNpIterResult > % np t r e s h o l d for disping i t e r a t e s result 50.0 < MinImproTol > 1.0000 e -3 % end of p a r a m e t e r % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -% [ dispFlag ] < BasicFlag > false < NetInfoFlag > false < ConvergenceFlag > false < StatFlag > false < ScalingFlag > 0 < NodalResultflag > 0 < LinkResultflag > false < QitersFlag > false < HitersFlag > false < timeFlag > false % end of d i s p F l a g % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -% [ controlFlag ] < SolverFlag > % 1 for GGA 2 for RCTM 3 for SMPA 4 for PDM 1 < FCPAFlag > 0 % end of c o n t r o l F l a g % - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -%

TE D

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

EP

Figure 11: A configuration file to run the RCTM in WDSLib

AC C

738

36

ACCEPTED MANUSCRIPT

Appendix E Nomenclature

740

Acronyms

741

CT

Co-tree

742

CTP

Co-tree pipes

743

DW

Darcy-Weisbach head loss formula

744

FCPA Forest-core partitioning algorithm

745

GGA

Global gradient algorithm

746

HW

Hazen-William head loss formula

747

WDS Water distribution system

748

RCTM Reformulated co-tree flows method

749

nnz

Number of non-zeros

750

STP

Spanning tree pipes

751

STN

Spanning tree nodes

752

ST

Spanning tree

753

Constants

754

g

Gravitational acceleration constant

755

ν

Kinematic viscosity of water

756

FCPA variables

757

C

758

Ec

759

Ef

760

Gc

Core subgraph

761

Gf

Forest subgraph

762

P

Permutation matrix for the pipes in the core, Ec , of the network

763

S

Permutation matrix for the pipes in the forest, Ef ,of the network

764

T

Permutation matrix for the nodes in the forest, Ef , of the network

EP

TE D

M AN U

SC

RI PT

739

AC C

Permutation matrix for the nodes in the core, Ec , of the network Set of core pipes (edges) in Gc Set of forest pipes (edges) in Gf

37

ACCEPTED MANUSCRIPT Vc

Set of core nodes (vertices) in Gc

766

Vf

Set of forest nodes (vertices) in Gf

767

Hydraulic variables for GGA

768

A1

Unknown-head node-arc incidence matrix

769

A2

Fixed-head node-arc incidence matrix

770

d

Vector of nodal demands

771

di

Demand of node i

772

D

Vector of pipe diameters

773

Dj

Diameter of pipe j

774

el

Vector of Fixed-head nodes elevation heads

775

elk

Fixed-head nodes elevation heads at node k

776

E

Set of pipes in graph G

777

EN

Vector of end nodes

778

EN j

End nodes of pipe j

779

f

Vector of Darcy-Weisbach friction factors

780

fj

Darcy-Weisbach friction factor of pipe j

781

F

Diagonal Matrix of generalized headloss derivatives when the headloss is modelled by either the

M AN U

TE D

EP

HW and the DW

782

SC

RI PT

765

[F ]jj

Generalized headloss derivatives for pipe j

784

G

785

G

786

[G]jj

rj |qj |n−1

787

h

Vectors of unknown heads

788

hi

Heads at node i

789

J

Jacobian matrix

790

L1a

Functions run once before multiple simulation

AC C

783

Full WDS graph

Diagonal matrix with elements rj |qj |n−1

38

ACCEPTED MANUSCRIPT L2a

Functions run once before hydraulic assessment

792

L3

Functions run every iteration

793

L2b

Functions run once after hydraulic assessment

794

L1b

Functions run once after multiple simulation

795

L

Vector of pipe lengths

796

Lj

Length of pipe j

797

n

Head loss exponent

798

nf

Number of forest pipes and nodes

799

nj

Number of junctions

800

np

Number of pipes

801

nr

Number of fixed-head nodes

802

nst

Number of ST pipes and nodes

803

nct

Number of CT pipes

804

q

Vector of unknown flows

805

qj

Flow in pipe j

806

R

Vector of Reynolds numbers

807

Rj

Reynolds number for pipe j

808

SN

Vector of start nodes

809

SN j

Start nodes of pipe j

810

U

811

V

812

V

Set of node in graph G

813

zi

Elevation at node i

814

αk

Interpolating spline coefficient

815

βk

Interpolating spline coefficient

816

θ

Vector as defined in Eq. (22)

AC C

EP

TE D

M AN U

SC

RI PT

791

Diagonal matrix of Schur Complement when headloss is modelled by HW Generalized Schur Complement when the headloss is modelled by both the HW and the DW

39

ACCEPTED MANUSCRIPT 

Vector of pipe roughness heights

818

j

Roughness height for pipe j

819

RCTM variables

820

Est

Set of ST pipes (edges)

821

Ect

Set of complementary CT pipes (edges)

822

K1

Orthogonal permutation matrix for pipes in the ST

823

K2

Orthogonal permutation matrix for pipes in the CT

824

L21

A part of a basis for the null space of the permuted node-arc incidence for the RCTM

825

R

Orthogonal permutation matrix for nodes in the ST

826

Vst

Set of ST nodes (vertices)

827

W

Schur complement for the RCTM

AC C

EP

TE D

M AN U

SC

RI PT

817

40

ACCEPTED MANUSCRIPT

Highlights

EP

TE D

M AN U

SC

RI PT

A library for the steady-state analysis of a water distribution system (WDS) An open-source C++ software implementation of a number of WDS solution methods A fast simulation platform for both once-off and multi-run simulations Several improvements to the existing solution methods have been made

AC C

• • • •