search

pyswmm / Stormwater-Management-Model

PySWMM Stormwater Management Model repository
Other
99 stars 77 forks source link

Addition of new Subarea Runoff methods #357

Closed schoeller closed 2 years ago

schoeller commented 2 years ago

Dear all,

I have received code for the Nash cascade runoff method. Programming background is mediocre. My question is whether changes to src/solver/subcatch.c -> getSubareaRunoff and a pull request are welcome.

Best regards

Sebastian

bemcdonnell commented 2 years ago

Hey @schoeller, thanks for raising this issue. I don’t know a whole lot about this method. Would you mind giving us some background and references? If the community is not interested, there is a nice alternative we can help you with to accomplish this!

schoeller commented 2 years ago

@bemcdonnell thanks for the response. The model is referenced on Wikipedia with more detail as below.

grafik

Cited literature source is "Nash, J.: A unit hydrograph study with particular reference to British catchments, Proc. Inst. Civil. Eng., 17, 249–282, 1960" which is unavailable to me. The algorithm was discussed on OpenSwmm a long time ago. It is used by the most prevalent sewer model in Germany. I wonder whethere there is any interest in extending the runoff models within the OpenWaterAnalytics project and ifso how to approach the matter, since there are unspeakably more models around.

dickinsonre commented 2 years ago

unspeakably more models around!!! There are a lot of models - I will also mention that Nash is used in Canada as well.

schoeller commented 2 years ago

@bemcdonnell in my understanding the first question to be answered would be: does the project want more runoff models to be included. Ifso second question would be to allow for modular behaviour.

bemcdonnell commented 2 years ago

@schoeller, I think the project should welcome all kinds of models. What I think we should do is develop a plug-in type architecture so that SWMM could simply "connect" to a separate hydrology model. Data could be passed from the engine to an outside functional process/data model. We could provide direct support within the existing input file (but that would required re-tooling SWMM as new models show up.) So I think I'm supportive contingent on the architecture! Are you working under any sort of grant or with any university?

dickinsonre commented 2 years ago

The complication is HOW integrated any non EPA SWMM hydrology is with the rest of subcatch.c. Does Nash hydrology use infiltration, evaporation, LID's and Groundwater? Question - is it really used by the most common sewer model in Germany? I cannot find a reference.

bemcdonnell commented 2 years ago

@dickinsonre yeah that's a great thought. I'm in favor of retaining the subcatment process as-is but building the plug-in type framework. This would require a secondary data source file (like hydrology.inp) for persisting the parameters. Each SWMM route step would call the external module asking it for new flows. Data from SWMM could just as easily flow to that plugin as required.

jennwuu commented 2 years ago

The complication is HOW integrated any non EPA SWMM hydrology is with the rest of subcatch.c. Does Nash hydrology use infiltration, evaporation, LID's and Groundwater? Question - is it really used by the most common sewer model in Germany? I cannot find a reference.

This may be possible using pyswmm: you can add flow into SWMM hydraulic network using generated inflow functionality in pyswmm. https://pyswmm.readthedocs.io/en/stable/tutorial/tutorial.html#generate-node-inflows

schoeller commented 2 years ago

The complication is HOW integrated any non EPA SWMM hydrology is with the rest of subcatch.c. Does Nash hydrology use infiltration, evaporation, LID's and Groundwater? Question - is it really used by the most common sewer model in Germany? I cannot find a reference.

@dickinsonre @dickinsonre thanks for your replies. The deep integration (with volume checking) is exactly the trouble I ran into. I forked the code and inserted the changes to my best knowledge in order to make the serial cascade model work. The given code comprises an approach to attempt integrating with other model components. When testing though the volume becomes incorrehent. With my humble spare time coding skills I could not proceed further. I have to leave this aside for now. FYI: correcting myself, that the Nash cascade model is not the most common hydrology mechanism around here. There's actually a multitude.

dickinsonre commented 2 years ago

Thanks, I know a bit about German Hydrology in my limited knowledge they seemed similar in concept and somewhat related to Nash. I may be wrong. As a side note we do have what we call German hydrology in the Innovyze An Autodesk Company software InfoSWMM and InfoWorks ICM - source was the program Storm https://www.sieker.de/en/fachinformationen/flood/hydrological-modelling.html

bemcdonnell commented 2 years ago

@schoeller, in the OWA-SWMM API there is an option to set a user-defined inflow to a node (which is separate from all SWMM's normal hydrologic processes). It sounds like you're programming in C. You have a couple of options for prototyping based on what I'm hearing:

  1. You could continue programming in C and make a copy of swmm5.h/c and use the toolkit.c https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/blob/76b8ae7e39f07a659b51284effafe668394d7f29/src/solver/toolkit.c#L2800 if you do it this way, you have discrete control over the equations and state while the simulation is running. You can get values out of the running simulation that you need as inputs to the German method.
  2. These api features have all been extended to PySWMM. We find PySWMM very easy to prototype new interfacing models with SWMM. If you want to test it, might be a much easier lift since there are so many debugging and plotting tools available.

Long-term, I think there is a good opportunity to incorporate hydrology methods through interfacing code. We will be happy to work with you when you can find the time to build and validate the method!