WaterSums models EPANET networks in the same way as
EPANET
does and can read/write EPANET network (.net) and input (.inp) files. In
WaterSums 2,
we extend this modelling to store
networks in a set of PostgreSQL database tables
using the Django object to relational
mapper to map the EPANET properties to RDBMS columns. Since we need to store
geographic information, PostGIS and
GeoDjango are used to provide spatial support.
This page has been updated from time to time – see the bottom of the page for the details of updates (last update was 9 September 2014).
One fundamental modelling choice is to decide the expected usage: single user or multiple users.
We have chosen to assume multiple users since this supports a single user with very little
added complexity for that user, but makes it easy for workgroups to share network data between
several, or even many, users.
The mapping of data fields from the EPANET network file format to PostgreSQL database columns
has mostly been very simple and direct – except where changes need to be made to support multiple users
or where some structural improvements have be made to remove confusion.
Multiple users need to be able to access their own networks easily without being distracted by the networks
owned by other users. WaterSums
uses the User class provided by the
Django authentication system
to provide this ownership and access support.
WaterSums projects can
contain multiple networks, but EPANET does not provide this support,
so for most of this article we will ignore the Project class which allows
multiple networks to belong to one project. Whereas
WaterSums has a user owning
projects which in turn contain networks, an EPANET-only model has users owning networks directly.
This is the modelling initially presented here. Note that EPANET uses the words ‘network’ and ‘project’
interchangeably. WaterSums,
however, uses ‘network’ as the equivalent of an EPANET network or project, while also providing a project
concept which represents a collection of networks.
EPANET uses object IDs (names) with certain uniqueness rules:
- The ID for any kind of EPANET node (Junction, Reservoir or Tank) must be unique across all IDs for all types of nodes. For example, a Junction and a Reservoir cannot have the same ID/name.
- The ID for any kind of EPANET link (Pipe, Pump or Valve) must be unique across all IDs for all types of links.
In the WaterSums
RDBMS data model, each class is modelled with a unique ID – including labels
and controls – and all network
classes also store a foreign key reference pointing to the network they belong
to. WaterSums
also adds extra attributes to some classes (for example a
‘deleted’ flag) but these are ignored here, as is all undo/redo
functionality.
To help match the ID restrictions of EPANET, all EPANET network classes are modelled
with a class Meta
parameter “unique_together
”
based on the network ID and the object
name of the class of object for which EPANET requires the name to be unique
(eg. all nodes must have a unique name so the TNode
“Name” value must be unique).
In summary, this is a modelling of an EPANET project file which is as close
to the EPANET storage format as possible whilst providing for multiple users
who can own multiple networks but do not normally wish to see the networks of other users.
Note that the storing of program settings and defaults is not included in this modelling,
only the storage of network information such as is saved by EPANET in .net files
(including default values which are set for a project).
The table below allows Django models to be developed. If there is enough response to this
article by comments below or through the Contact page, we will
release a simplified version of the models file(s) after the final release of
WaterSums
2. In fact, if there is enough interest in helping to make sure
that a Django-based RDBMS schema for EPANET is made available and maintained as an open
source project, WaterSums would also be happy to contribute all of this information to the task.
Please contact us if you are in a position to help with this.
Class name |
Parent class |
Table name |
Comments |
User |
N/A |
auth_user |
Django default |
– |
– (abstract) |
Network analysis options which are used in more than one place in EPANET: networks and program defaults. Hydraulic options: |
|
wsproject_toptionsdata |
Network analysis options. Quality options: Reactions options: Time options: Energy options: |
||
– |
wsproject_tmapoptions |
Network map options: |
|
– |
wsproject_calibdataarrays |
Network calibration data for nodes Calibration files for nodes: Calibration files for links: |
|
– |
wsnetwork_defprops |
Network property defaults for different Junction defaults: Reservoir defaults: Tank defaults: Pipe defaults: Pump defaults: Valve defaults: |
|
– |
– (abstract) |
Colours used for the colour-coded display of network analysis results. 5 colours for the 5 value |
|
wsnetwork_analysisdisplayconfiguration |
Values used to separate value bands in the colour-coded display of network analysis results. These values are also displayed on the node/link legend. 4 Map legend values for each Node parameters Link parameters In EPANET, these values are edited with the Legend Editor Note that in EPANET code, there is an |
||
– |
wsnetwork_network |
A Network must belong to a User. Some data fields stored in the database are not stored in EPANET .net files: Fname (not essential, but can be helpful in identifying where the From here on, this class is defined (as closely as possible) to Ver, AnalysisOptions (mandatory one to one link to TOptionsData object), AutoLength. ( MapLowerLeft (as PointField), MapBackDropFilename and MapOptions (mandatory one to one link to TMapOptions object).
AnalysisDisplayConfig (mandatory one to one link to AnalysisDisplayConfiguration object), CalibData (optional one to one link to CalibDataArrays object), IDIncrement, DefaultProperties (mandatory one to one link to DefProps object).
LMargin, |
|
– |
– (abstract) |
A NetworkObject must belong to a Network, |
|
– (abstract) |
Adds Name (EPANET ID), Description and Tag. |
||
wsnetwork_tnode |
Adds Location (as a PointField), |
||
wsnetwork_junction |
Adds Elevation, Demands are somewhat mixed up in EPANET. A more exact mapping of the modelling in EPANET |
||
wsnetwork_demand |
Demand(s) for a given Junction. Note that since this class inherits from |
||
wsnetwork_reservoir |
Adds Head, HeadPatternID, |
||
wsnetwork_tank |
Adds BaseElevation, MinimumLevel, InitialLevel and MaximumLevel, |
||
wsnetwork_tlink |
Adds StartNode, EndNode and Path (as a LineStringField). |
||
wsnetwork_pipe |
Having Adds Length, |
||
wsnetwork_pump |
Adds Power, |
||
wsnetwork_valve |
Adds Diameter, |
||
wsnetwork_curve |
Adds Name, |
||
wsnetwork_pattern |
Adds Name, Description and Coordinates (as MultiPointField). |
||
wsnetwork_control |
Simple controls. EPANET does |
||
wsnetwork_rule |
Rule-based |
||
wsnetwork_maplabel |
Adds Name, Text, MeterNodeID and MeterLinkID |
For completeness, the description change for the User class, the modelling changes necessary to the Network class and the
WaterSums Project class itself are shown in the table below.
Classname |
Parent class |
Tablename |
Comments |
User |
N/A |
auth_user |
Django default |
Project |
– |
wsnetwork_project |
A Project |
Network |
– |
wsnetwork_network |
A Network must |
Update history
- 9 September 2014 to remove invalid Length attribute from Valve and change name of Tank attribute BottomElevation to BaseElevation
- 6 September 2014 to change point storage for Curves and Patterns from LineStringFields to MultiPointFields.
- 4-5 September 2014 to remove LinkLegendLength (1-4) and LinkLegendLinkQual (1-4) from
AnalysisDisplayConfiguration class and add many links. - 25 August 2014 to add NotationSize to TMapOptions class.