Version 2.1 release plan

I’d like to give a brief update and draw your attention to some progress over on GitHub. The active developers there would like to get a v2.1 release organized and wrapped up - this would be the first public release of EPANET code since 2008, and we are all super excited about it.

We are asking for help in finalizing the list of items to be addressed in v2.1. Please note that one of the major goals is expediency - in other words, this release should focus on fixing known bugs and stability issues in the toolkit, with perhaps some minor expansions on the API for user convenience; we are not talking about overhauling any engine code or moving to object orientation just yet.

Please have a look at the issues related to the v2.1 milestone and speak up if you feel that something important is missing, or if an existing issue should be included in this milestone.

And of course if you have any programming experience, engineering knowledge, willingness to create documentation or to test the code, then welcome to the fold. You are the future of this software.


Model users want to assign useful names to pumps, important valves, tanks, reservoirs, SCADA monitoring points, etc. In most models we see these being relegated to the Epanet input file comment string associated with a model element, because the existing ID field is needing to be consistent with a GIS element id. Epanet should support this better, both in the input file and through the API.

I note that there is the LABELS functionality currently, but that is designed to associate a string with a set of coordinates. So it seems that LABELS are more for natural or non-network features, like a lake. That’s starting to smell to me like a legacy feature, since any viable future version of Epanet should have good support for base maps that handle those needs.

So in summary, I think that each junction, pipe, tank, reservoir, pump, valve should have a unique ID, and also an optional string NAME, and those characteristics should be accessible via an expanded API.

I’ve added this to the Epanet issues on github.


Things are coming closer for the release of version 2.1. In the past weeks we were able to close some issues tagged for this milestone and had good discussion on the remaining items.There are still open issues for 2.1 so here is the current status:

  1. Build files - will support Windows, Mac and Linux. DLL and EXE. 32 and 64 bits.

  2. Testing protocol - this is probably the most important issue now. The basic plan is:

  • have a set test INP files. I will be putting up list of available networks or we might use network collected by the EPA. If you can share a network please let us know.
  • use a script (thanks @samhatchett) to produce the binary output files with the new code base and:
  • compare the new output file with the known binary file of the old, and trusted, code. Thanks Bryant for volunteering to build the script using also @Tryby_Michael’s binary file APIs.
  • finally use travis-ci to automatically run the tests (sample output demo).
  1. documentation - we decided to go with doxygen for APIs documentation. @samhatchett volunteered for this task but any help would be much appreciated. This involves mainly in copying and pasting text in a specific markup. General documentation is currently available on GH Wiki (thanks @Mariosmsk for your contribution here).

Before we wrap up version 2.1 we need to agree on the license. The EPA’s version is in the public domain and we are considering sticking with that. This is the time to speak up.

As Sam said:

Thank you all.


Considering the public domain, first note that it is not a licence, but a specific IP status.
In the OpenSource world, we usually do not advise to distribute software in public domain, but to stick a specific licence to it, which could be very similar to public domain.

The reason is quite simple : in the European-style IP laws, it is not possible for someone to willingly put any creation of its own into the public domain. Hence, any contribution to a software in Public Domain from European people would lead to juridic uncertainties. The author rights in Europe are inalienable, and the creation process for FOSS should reflect this if you want to attract international contributors and have a good legal foundation.

If you want something as close as possible to Public Domain, I would advise to use an MIT or Apache licence.
CC0 also correspond to this spirit, but is not intended to be used for source code.

Should you need more information on this, I will be glad to explain more.

The licensing issue is always terribly confusing whenever it comes up. One major hurdle to licensing we’ve seen is the first line of most licenses:
Copyright (c) <year> <copyright holders>

… who are the copyright holders? US Gov’t employees can’t hold or transfer copyright to works produced within their official duties, so there’s a slightly complicating factor. Beyond that, there will be a list of over a dozen authors. If these are to be the copyright holders, then any change of license (particularly a change to less restrictive terms) would require written approval from all of these people - some of whom may no longer be living at the time of the change.

For this reason, many projects have a CLA - contributor license agreement - that assigns copyright to a third party, usually an organization. We are not organized in this fashion; there is no legal entity for the OSS epanet project as of right now.

Additionally, there is uncertainty about how/if the USEPA can distribute this software (if they wish) as updates are made available, if the software is licensed.

So our instinct has been to look to the SQLITE license model as an example of public-domain software that has been readily adopted by industry and redistributed by commercial interests many times over, or use the Unlicense which also has a CLA of sorts.

Failing international agreement on whether a person can dedicate code to the “public domain”, I would perhaps suggest an MIT-style license with AUTHORS.txt as the “copyright holders” but with the required attribution clause removed.

Please, @vpicavet if you have more info about international requirements we would love to hear.

@vpicavet and @samhatchett as a reminder, there is an open threat for discussing EPANET licensing/copyright, so perhaps that discussion can continue there :slight_smile: : Open source EPANET license

Let’s continue the licence discussion on the open “thread” : Open source EPANET license