Many software programs that model water supply networks use the public domain EPANET modelling engine for analysis. EPANET defines many different types of object which can be contained in such networks and settings for simulation of events in the networks. EPANET also defines an input file format which can describe these objects and settings.
In two earlier series of posts, we have looked at EPANET and some simple modelling related to it because it is a good basis for demonstrating modelling options and methods. The first series looked at translating the input file format to a very simple set of database tables. The second series took that set of database tables and converted them into several Django models and considered some of the differences that result.
WaterSums is a software product that models water supply networks. It is another project of mine – one which has not been receiving enough attention from me over the last couple of years – but one which has some features that are useful in a consideration of data modelling.
When integrating a modelling program with a marvellous toolkit such as EPANET, the modelling software must be able translate information in two directions:
- writing network information in a form that will be accepted as valid input by the EPANET toolkit, and
- reading the analysis results written by the EPANET toolkit.
Of course, error handling is also required since the user must be able to locate and fix any errors that are identified by the toolkit.
WaterSums models water supply networks using its own internal format.[1] Of course, the information can be stored in any format at all: the format doesn’t matter. What does matter is to be able to write the network information in a format that the toolkit can read and understand. Likewise, the method of displaying the result doesn’t matter either, as long as the program can read and understand the toolkit output format so that the results of the analysis can be presented to the user.
This requires care, but is not difficult.
The EPANET interactive program stores its network information in a single file using the data model defined in its source code.
WaterSums does the same, using its own data file format – as well as supporting the file formats used by EPANET.
However, WaterSums also wanted to be able to store network data in relational databases to make it easier for the information to be used by external tools and to provide a web-based analysis tool.
This was where Django came in. Django is a good fit since it provides an Object Relational Modeller which can easily map objects to database tables.
Using Django for this purpose required us to model water supply networks as they are understood by EPANET, and that is what this article is about.
Much of the early parts of the modelling are just the same as in the case study shown in a couple of earlier newsletters EPANET Input Files in Django, Part 1 (#25) and Part 2 (#26), so we won’t go into those parts much. These parts are fairly simple.
What is interesting – and quite typical of input files – is that the most complex parts of the modelling relate to the definition of defaults, settings and methods, not the equipment being described.
Leave A Comment