EPANET 3 Needs Assessment

#1

On the heels of the WDSA conference in Cartagena, I’d like to set up a thread for community feedback for EPANET V3 Software Requirements. I was on FaceTime at the meeting this evening, and it was great to see so much interest. Thanks for showing up! We need to document everything here, because as we all know, conferences can make us excited but forgetful.

As you are all aware, a large codebase has been set up on GitHub at epanet-dev - this is a C++ object-oriented epanet development project donated by @LRossman. The EPANET open-source development committee (@demetrios, @eladsal, and @samhatchett - formed as a sub of the WDSA standing committee) has suggested that this code be used as the central starting point for developing the next version of the toolkit.

As we get acquainted with the new code, we will all undoubtedly have ideas for making it better. Our ideas will have much to do with how we each wish to use the toolkit. Many ideas were expressed in Cartagena about what some of those improvements might be. To accommodate the various use cases for the toolkit, we need a deep and accurate assessment of need.

One effective way to boil down requirements is to phrase them as “user stories”. This allows us to evaluate needs on a somewhat regular footing, and eventually translate the most relevant or important into formal software requirements, and eventually an architectural plan. To get a more in-depth survey of user needs, try to structure your requirements using the following guide. Of course, if you think that your needs can’t be expressed in this way, then just write from the heart. Please include as much information or exposition as needed to convey the important concepts.

The User Story format is "As a ......, I want to ...... so that I can ......"

For example,

As a commercial software developer, I want to have a lightweight hydraulic EPS simulator so that I can quickly build models from shape file data and let my users run scenarios.

As a researcher, I want to run huge numbers of simultaneous simulations quickly so that I can say something about water distribution systems from a probabilistic perspective.

As a water utility expert, I want to simulate the transport and reactions of chemicals in a water system so that I can alert water customers to potential contaminants.

… and so on.

Is this the only way to interact with the project? Absolutely not! Create new topics on this forum, discuss how you use the software, how you have changed it, how you want to use it. And then go on over to the GitHub project site, download and build the project, file some Issues, get into fights (i mean constructive conversations) about minor implementation details. This is an organic process, but we need your involvement to make this project succeed.

#2

As a researcher, I want to analyze different managerial actions / scenarios about network design (including the design of pipe, tank and pump) so that I can optimize the system (in terms of both hydraulic and energy) in order to create more efficient pumping systems for water supply systems. (analysis for hydraulic reliability and energy efficiency in water dist. networks are my main focus areas).

In these analyses, integration of some map functionality in EPANET such as a basemap for network drawing, importing and exporting networks as DWG or SHP file formats and ability to work with coordinate systems in drawing networks will be very helpful for me.

2 Likes
#3

Thanks to @sarptas for getting the ball rolling here. I’ve been thinking about this question for a few days now in context of the early steps of development over on the project site, and would like to share my own “needs”.

As a software developer, I want to embed a hydraulic simulation toolkit within a data integration environment so that I can build models on-the-fly, run simple simulations, and change the way that models are used in industry.

I’ve been producing commercial engineering software for the past 5 years or so, using the v2 toolkit, and I’ve had to really jump through some hoops to use epanet in a simple way. The package assumes a certain mode of operation - that you have an input file, and you want to produce an output file (or access the results from an output file via the API). To my knowledge, all users of the toolkit have to deal with these fundamental I/O assumptions, and it is quite difficult rearrange the tool to accomplish what I’m after; to build a model at runtime with custom code (without using the inp file), modify that model, and run simulations in an ad-hoc fashion. Epanet (especially v2) really wants to be a first-class citizen - to call the shots: the engine itself assumes that it will be reading an input file, and the engine assumes that it will be writing results to disk. It would be better for my needs, going forward, that the engine not make any such assumptions. It would be totally reasonable to accomplish this goal in a way that is completely transparent to users of the existing toolkit - just by breaking the code up into separate libraries that manage each task: input, computation, results, and the command-line executable.

The C++ development version looks like it’s going to be amenable to the above concerns, and we’ve got some issues and conversations going about adjusting the organization of the code to do this. Does anyone else agree/disagree with my reasoning? I’m truly curious to hear from you.

1 Like
EPANET 3 software architecture
#4

As somebody working on leakage modeling, I would like to see the option of having multiple emitters at each node. It’s becoming clear that to model leakage accurately, a modified orifice (also called FAVAD) formulation should be used. This formulation requires two emitters at each node with leakage, one emitter having an exponent of 0.5 and the other 1.5.

Our research has shown that modeling the behavior above with a single power equation (i.e. an emitter) is problematic. For instance, the equivalent emitter exponent for a leak is not constant but varies with pressure - thus introducing errors when modeling it at pressures far away from the initial value. Under certain conditions the equivalent exponent approaches infinity, which exacerbates the problem.

Besides the two emitters required for leakage, additional emitters may be desirable to model pressure-dependent demands. These emitters may even require individual exponents rather than global ones.

2 Likes
#6

As a research scientist, I like to envision applications for Epanet ranging from standard simulations that can run on a single system to applications at the intersection of the big data and high performance computing domains.

Epanet has certainly been used in a wide range of applications because of its robustness and efficiency. However, as pointed out by Sam, it is often up to the user to figure how to interact with the current input/output architecture. I totally agree with the idea of moving towards a modular design. The object oriented paradigm (OOP) is fully amenable to modularity because it clearly separates/associates data and functionality. And a good OOP design is granted to allow for the range of present and future applications I am aware of.

As a learning exercise, I am trying to draw high level diagrams of the current and “modular” architectures, in order to understand what the main transitioning challenges would be and to hopefully start a discussion. In building the latter, it would be very useful to have input on use cases that illustrate the different ways in which the community is using Epanet’s I/O design. I think many applications can be synthesized in a number of general cases. I have a few examples, Sam probably has many and others as well.

@samhatchett: could you please illustrate in a bit more detail “to build a model at runtime with custom code (without using the inp file), modify that model, and run simulations in an ad-hoc fashion.”?

Other examples are welcome!

#7

At the meeting in the WDSA congress held in Cartagena last July, it was decided to open a period of discussion on the contents that should have the new version of EPANET. I basically agree with the approach of Sam, based on each member of the community should contribute their suggestions or interest in the format "As a …, I want to … So THAT I can … ". In any case, I think we should focus ideas to progressively organizing information.

In my opinion the contributions should focus on several levels or layers, so that information could be organized and understood easily. Therefore, I have attached a quick compilation of ideas about the capabilities that should have the new EPANET engine. This information has been grouped in four basic levels. The basic idea is to collect the interest of different users. You may have users interested in certain levels that are not specifically interested in other levels of model development. For example, some may be interested in the numerical solution of the equations; other users can focus their interest in using the model as a black box for use in
optimization problems, and others could be interested only in the pressure driven models to represent the behavior of consumptions or leakages.

Hence, within each level I have tried to bring only a few ideas to stimulate debate and contributions of this community. The idea would be discussing the features and characteristics that must be included in each of them.

Level 0. Solving the equations of static analysis.

  • Will it be possible to particularize the system of equations to solve?

  • What solution approach should be used: loop equations, node-loop equations, node-equations?

  • Will we continue using the Todini’s gradient method as solution algorithm for steady
    flow?

  • Do we consider to include the possibility of using different algorithms?

  • Are we going to use optimized techniques for handling sparse matrix?

Level 1. Dynamic modelling of the network.

  • What criteria will be used for the representation of demand patterns?
  • Is the demand considered constant during the interval calculation? Shall we consider the slope of the demand pattern curve?
  • What * are the criteria for variation of the properties of the different elements (pumps, valves,…) over time?
  • How are we going to make the integration of the continuity equation in the tanks?
  • What controls or control types will we define to manage dynamic network performance?
  • Will we develop a pseudo programming language for defining complex controls?
  • Are we only going to use EPS (quasi-steady) models? Or will we consider water * hammer models, similar to how it is done in EPASWMM? Perhaps this issue could * be itself a Level 4 or 5 of the problem.

Level 2. Specific modelling of the behaviour of each element in the network.

Level 2.1. Pipes model.

  • Do we keep the three current models for calculating losses (Darcy-Weisbach, and Hazen-Williams Manning)?
  • Do we include some additional equation for calculating the friction factor Darcy?
  • Do we consider the flows are concentrated at the ends of the pipes? Or conversely, do we consider the ability to define consumption distributed along the pipes?
  • Do we keep the hypothesis that the lines must be completely filled or consider the
  • possibility of networks working with free surface?

Level 2.2. Nodes model.

  • How do we represent independent consumption of pressure? Are they fixed regardless
  • of the pressure value? Are they fixed even when the node is disconnected from the network?
  • How many and what are the pressure-driven models to consider? Should these models be customizable?
  • In general terms, what actions should be taken if the pressure in a node is negative?. What if the node is disconnected from the network?

Level 2.3. Tanks model.

  • What is the reference geometry of a tank? Is it circular, rectangular, or is it enough to indicate the cross section?
  • There are different configurations of deposits. Will we consider only the current model that considers the entrance to the tank at the bottom? Are we going to consider that the entrance could be at the top?
  • Will all tanks be atmospheric, or else will we consider pressurized tanks?
  • How will we define variable section in tanks?

Level 2.4. Reservoirs model.

  • Will the reservoirs be able to vary their level over time? How are we going to * define this variation?
  • Would it be interesting that the pressure variation was based on the flow?

Level 2.5. Pumps model.

  • It is necessary to eliminate behavioral representation of a pump based on its power data. This model generates a hyperbole head curve that in no way represents the behavior of a pump.
  • Do we keep the current form of representation head pump curve (H = H0 - A · Q ^ B)? Do * we consider the possibility of adding other forms of representation, such as * polynomials of degree 2 or 3?
  • Include * changes made by Marci et al, in calculating the efficiency of the pumps, when rotating at different speeds from nominal.
  • Do we include the efficiency of frequency inverters for pumps rotate at different * speeds?
  • Do we * consider the possibility of including the NPSH curve of the pump in order to analyze pump cavitation?

Level 2.6. Valves model.

  • Do we keep the current types of valves model of EPANET?
  • Do we consider the check valves as a property or condition of pipes? Or on the contrary, do we consider it as an additional type of valve?
  • Would be useful some sort of combined valve? For example, a pressure reducing and sustaining valve, so that one of the setting had priority over the other.
  • Is the degree of opening of the valve should be added as a parameter to consider in the model?
  • Should we consider parameters to define cavitation in a valve?

Level 2.7. Other elements.

  • Generally, I have collected the elements defined in the current versió of EPANET. But, would it be interesting to define other types of elements of water distribution networks such as turbines, filters, …?

Level 3. Applications based on the recursive performing network analysis.

  • Pipe sizing design problems, pump or valves selection, …
  • Optimization problems based on the performance of the network.
  • Network calibration.
  • Network clustering and sectorization.
  • Network sketonization.

I hope your comments on whether this structuring of the ideas you think is correct or not.

#8

As a researcher that uses heuristics optimisation algorithms, I would like to be able to run simulations quickly on my desktop. I would also like to be able to run parallel simulations on multiple processors.

I would like to be able to modify the demands that are in different categories (but inserted at the same node) and have the possibility to add a power demand charge (or different power demand charges) to different pumps in the system.
I would also like to be able to optimise rule-based controls and have the possibility to use the days of the week in the rule-based controls (as often the weekends are off-peak tariffs periods).
I would also like to have a more stable version of EPANET when multiple valves (e.g. PRVs, FCVs) are inserted in the model.

These next points may be a bit too much, but, as stormwater use and aquifer recharge are becoming more common, it would be nice to be able to simulate how the aquifer impress and drawdown levels change with the pumping and be able to simulate evaporation, environmental flows and other processes/factors that are not taken into account in conventional water systems.

#9

With the new 2.1 version you can set the demand for the categories. Look at ENgetnumdemands, ENgetbasedemand, ENsetbasedemand and ENgetdemandpattern. We are missing these functions in the documentation.

#10

As a researcher and consultant with experience in developing countries, I want to have the possibility to simulate intermittent water distribution networks, so that I can produce a variety of operational and design solutions for water scarce cities. Indeed, some consultants working in intermittent systems I know have been modelled these with EPANET, assuming a continuous, pressurised condition. Time of filling up of the piped network, intrusion of groundwater in empty conditions and supply schedule by sectors would be very useful.

I will also like to see advances towards integration of systems, using standards such as WaterML, online retrieval of real time sensor data and cloud computing options for optimisation and uncertainty analyses.