If a link’s offset is changed and Elevation Offsets are being used, then the conversion of the new offset to a an internally used depth offset gets messed up.

https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/blob/develop/src/toolkitAPI.c#L452-L499

1. This will enable us to run multiple models within a single instance of SWMM.
2. Will also let us safely set variables with the API assuming a user can use multiple threads to talk to the API. Mutex?

This repo is forked from USEPA. We need to merge in any community additions from https://github.com/OpenWaterAnalytics/SWMM

If we need to keep commit attribution, theres a pretty good guide for stitching separate repositories here:
http://bugsquash.blogspot.com/2010/03/stitching-git-histories.html -- but this may not be an issue right now.

I think creating conda packages for this different products would definitely allow a bigger audience working on engineering and scientific applications. I would like to create conda packages for the different projects hosted at open water analytics.

Are you familiar with conda? and Anaconda?

Since this is an open source and community maintained version of the swmm engine, I am thinking of naming this (conda) package as openswmm or open-swmm. Once the packages are ready one could cross platform install swmm as

conda install open-swmm (or whatever name we think is best)

Thougths?

Using conda would really increase outreach f this prohect as it would allow for easy creation isolated environments for development, work and testing (travis ci etc...)

I think it's time to dream up an Input API that will find its way into the formal distribution of SWMM. :)

@rkertesz @fmyers @michaeltryby

Hi,
Is there a reason why there is no makefile for creating a shared object library of swmm on Linux?
If I uncomment #define SOL in swmm5.c, then none of the makefiles work in _build/GNU-DLL or _build/Linux

This might not be a priority, or we might lack resources to pursue this endeavor. I think that having a headers.h which itself imports almost all (have not checked) headers in the project makes the process of decoupling the codebase more difficult. I argue it would be better to import the headers that are strictly required for a given file. and this could be a first step in the decoupling/unit-testing process

Hi @samhatchett, I am trying to get this build for OSX and in the process I am getting the following warnings:

Building C object CMakeFiles/swmm.dir/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/roadway.c.o
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/roadway.c:27:37: warning: useless storage class specifier in empty declaration [enabled by default]
 static enum RoadSurface {PAVED = 1, GRAVEL};

Building C object CMakeFiles/swmm.dir/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/swmm5.c.o
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/swmm5.c: In function ‘swmm_open’:
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/swmm5.c:313:4: warning: implicit declaration of function ‘_fpreset’ [-Wimplicit-function-declaration]
    _fpreset(); 

Building C object CMakeFiles/swmm.dir/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/toolkitAPI.c.o
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/toolkitAPI.c: In function ‘swmm_setSimulationDateTime’:
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/toolkitAPI.c:98:4: warning: implicit declaration of function ‘floor’ [-Wimplicit-function-declaration]
    TotalDuration = floor((EndDateTime - StartDateTime) * SECperDAY);
    ^
/Users/gpena-castellanos/continuum/Stormwater-Management-Model/src/toolkitAPI.c:98:20: warning: incompatible implicit declaration of built-in function ‘floor’ [enabled by default]
    TotalDuration = floor((EndDateTime - StartDateTime) * SECperDAY);

And finally, this error:

Linking C shared library bin/libswmm.dylib
Undefined symbols for architecture x86_64:
  "__fpreset", referenced from:
      _swmm_open in swmm5.c.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [bin/libswmm.dylib] Error 1
make[1]: *** [CMakeFiles/swmm.dir/all] Error 2
make: *** [all] Error 2

Thoughts?

Unit conversion from CFS -> your flowrate step was missed in the last update. Fix will be committed in a minute.

Hi,

I am trying to assimilate the intended workflow with the swwm python tools. Questions I could not answer by scanning the source tree and the docs there:

1. How should tools/ by installed for the python search path?

2. Are this tools within a module? e.g. can one do from .tools import swwm-reader?

3. What python versions are supported? python 3?

I have developed a random network generator and I would be happy to make it compatible with your tools if I understand how to use them :D

Thanks

@bemcdonnell could you register at

https://anaconda.org

So I can add you to the

https://anaconda.org/openwateranalytics

Organization?

Update new functions

@fmyers caught a small bug that is almost harmless.

In routing.c under routing_execute() there is a loop that sets the oldLatFlow to the newLatFlow for all the nodes:

    // --- initialize lateral inflows at nodes
    for (j = 0; j < Nobjects[NODE]; j++)
    {
        Node[j].oldLatFlow  = Node[j].newLatFlow;
        Node[j].newLatFlow  = 0.0;
    }

then all the lateral inflows are added to the nodes

Then it jumps down and loops through all the nodes again calling a function in nodes.c node_setOldHydState()

            for (j = 0; j < Nobjects[NODE]; j++)
            {
                node_setOldHydState(j);
                node_initInflow(j, routingStep);
            }

where node_setOldHydState() also moves OldLatFlow to NewLatFlow

void node_setOldHydState(int j)
//
//  Input:   j = node index
//  Output:  none
//  Purpose: replaces a node's old hydraulic state values with new ones.
//
{
    Node[j].oldDepth    = Node[j].newDepth;
    Node[j].oldLatFlow  = Node[j].newLatFlow; // <- Not Needed (according to Lew and Fred).
    Node[j].oldVolume   = Node[j].newVolume;
}

I'm not convinced we are using the best branching model for this project. PySWMM brings everything back to the master branch, which I find helpful and simple. This project is inherently different since (at least at the moment) we are working toward multiple releases of SWMM (5.1.13 - bug fixes and 5.2.0 - the new API).

Seems like people that are new to the project could become quickly frustrated. Thoughts?

It would be useful to be able to build the SWMM source as an command line executable in a Linux environment. A Linux build will make it more convenient to run SWMM on web servers; this could make it easier to scale up model runs on powerful machines (on AWS or whatever you prefer) without having to pay for Windows virtual environments.

I've created a simple Linux Makefile that I've successfully tested on a Digital Ocean droplet running Ubuntu 14.04. This is in my linux branch.

From toolkitAPI.C... The EndDateTime is set correct but the TotalDuration was not updated. Probably need to add a function to re-validate the values before the simulation starts

// --- compute total duration of simulation in seconds
TotalDuration = floor((EndDateTime - StartDateTime) * SECperDAY);

I will start diving more and more with the codebase of SWMM in the following months (~6 months) and one of the things I have been looking around is for unit test libraries/frameworks for C.

This discuss some options.

• https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C
• https://stackoverflow.com/questions/65820/unit-testing-c-code

https://sites.google.com/site/ruslancray/lab/projects/cunittestingframeworkswithcodecoveragemetrics/c-unit-testing

I have no experience with any of the one mentioned but with CI in place, its a good opportunity to try some options with some part of SWMM. We will need to decouple modules a bit, but for instance the shape.c seems like a good candidate (pretty small and just some methods to test) to start with.

What could be some loose list of requirements? for example,

• Test framework should be for C and C++, in case the code uses C++ at some point in the future?
• If it is a C only framework, tests would be much easier and simpler to write

CUnit, Check seem to be the classic ones, but https://github.com/Snaipe/Criterion looks promising. CMocka also looks simple. Or we could use a C++ unit testing framework like google test, but that would require C++ knowledge for running the tests.

Steps:

1. Decouple the code of shape.c so it can be compiled as a standalone thing (if not possible already)
2. Write some basic unittests for the file using some of the tools/frameworks available.
3. Pick something to work with :-p

Thoughts @bemcdonnell, @michaeltryby ?

Issue Copied from USEPA/Stormwater-Management-Model

We need a set of models that will be run in CI for regression tests.

@aerispaha, @mehmetbercan, @rkertesz, @abhiramm7 would any of (or all of, or some of) you guys be interested in making a set of simple models that isolate some process thing? Ideally these models will run really fast and encompass all of the necessary components without the need for support files.

For example:

• RTK's
• Subcatchment Runoff
• LID's
• Controls
• GW/Aquifers
• (dare I say) Water Quality

We could use something like https://clang.llvm.org/docs/ClangFormat.html, once tests are implemented, to keep the code base in a consistent state. Also this would be enforced on the CI. The idea is to not waste developers time in style reviews but in code reviews, what the code is actually doing!

NCDC CDO 15 minute precipitation data product can be ordered in metric (MM) or standard units (HI, HT). SWMM does not recognize when the units of the supplied data file are in MM it assumes they are either in HI or HT hundred or tenths of an inch respectively. It appears that the rain units attribute for the rain gage selected by the user are being ignored.

This bug is further compounded because the units flag is not being set correctly when ordering data from NCDC CDO. According to the specification 15 Minute Precipitation Data Documentation dated February 2016, the units flag reflects the the units in which the data values are given. This, however, is not the case in practice.

A potential solution to this problem would be to check for the unit flag in the data file. Which currently isn't happening. Another possible solution would be to honor the user indicated units provided in the rain units attribute.

Also put in new directory run/main.c

This is a bug in SWMM v5.1.12

When a text based interface file is used to define nodal inflow and infiltration the inflow is not being added properly to nodal lateral inflow. The flow values in the interface file are not being parsed and converted from string to double properly.

Automated regression testing would be a great feature as SWMM is moved toward open source development. The EPANET development team has spent a lot of time on this issue (OpenWaterAnalytics/EPANET#16 OpenWaterAnalytics/EPANET#54). They have implemented a build pass/fail testing protocol that uses Travis-CI testing framework. I've been a bit out of touch with what they have recently been up to, however, they have decided on a set of canonical models that are used for the regression testing. Travis-CI pulls down any committed code and follows the routine you ask it to (I.e. Compiles your code, runs the models (Pyswmm in our case), "mathematically" diffs the outputs (Python wrapper to swmm outputAPI), and returns a true or false for pass/fail, respectively.)

Two levels of regression testing would be nice. 1) a tool that works with Travis-CI (returns a pass fail) and 2) a tool that gives you the details. The latter could help us in justifying any changes to the model that you wanted.

Between Pyswmm and the Python outputAPI wrapper, the tools are already available to get this up and running. However, the SWMM community might benefit from deciding on how the time series "diff" is performed between new engine and old engine.

I can put together a small roadmap for this once the discussion begins.

You all may have some thoughts on the issue?
@samhatchett @michaeltryby @rkertesz @fmyers @lmontest

MIT, BSD, APACHE etc?

Travis-CI build is failing on Linux due to cmake build.

$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at CMakeLists.txt:28 (target_compile_definitions):
  Unknown CMake command "target_compile_definitions".

Some VS solution settings do not export this function correctly.

all #include <malloc.h> lines should be replaced by <stdlib.h> as the former is not always available on all systems.

And document the API!

raised this issue to address the code style suggestion by @michaeltryby made in PR #31.

There should be a simple swmm -h and swmm --help and swmm -v and swmm --version for the command line. This is also a simple way to check compilation was successful when doing the conda build.

See https://github.com/conda-forge/staged-recipes/pull/3115/files#diff-b70c769d454ac533a4a434d2472e57f6R32

As discussed in #57 there is some common ground between Epanet and SWMM that could be unified in a single codebase (additional separate library/repo?)

Let's use this issue to discuss how we could achieve this. There is the issue of making SWMM more OO oriented (using C++) as Epanet is already moving in that direction, I don't know if that is also a separate issue/discussion but I guess we can have that talk here.

Please share your thoughts @samhatchett , @bemcdonnell, @michaeltryby

Look into:
https://baptiste-wicht.com/posts/2014/04/install-use-clang-static-analyzer-cmake.html

Disaggregate the input file parser function

int inflow_readExtInflow(char* tok[], int ntoks)

into two pieces.