Use the System Graphs in #SWMM5 to show the delay between Inflow and Outflow

Editing and Graphing Gauged Data in XPSWMM

Note:  Editing and Graphing Gauged Data in XPSWMM for Runoff Nodes, Hydraulic Nodes and Links.  Here is a sample of the data.

Pipe02   140.00200801011207     1.915

Pipe02   140.00200801011208     1.308

Pipe02   140.00200801011209     1.015

Pipe02   140.00200801011210     0.840

Pipe02   140.00200801011211     0.721

Pipe02   140.00200801011212     0.638

How to save SWMM5 output to InfoSWMM, InfoSWMM SA and XP-SWMM Calibration Files

In a world that increasingly asks us to move faster, and do more to be effective we need better ways to do our analysis.  One of the hardest tasks we have is to quantify the difference between our simuluation engines.  All of our Sewer and Storm software are hyper complex with interconnected options for all elements in the network.  One way to help with these comparisons are graphs using the calibration files of SWMM5, InfoSWMM, InfoSWMM SA and XP-SWMM.  The remainder of this blog describes the steps in using a QA/QC version of SWMM 5.1.012 to make these calibration files.

Step 1.   Create the Calibration Files in SWMM5

Step 2.  Export to SWMM 5 from InfoSWMM

You can export to SWMM5 using the Exchange/Export in InfoSWMM or the Data/Export EPA SWMM5 in InfoSWMM SA

Step 3.   Export to SWMM4 from XP-SWMM

Step 4.  What are the name of the Calibration Files?

There are nine calibration files made for InfoSWMM: StorageVolume, Runoff, Groundwater Flow, Groundwater Elevation, Node Depth, Node Lateral Flow, Link Flow, Link Velocity and Link Depth.  There are three calibration files made for XPSWMM: Node Head, Runoff at a Node, Link Flow.  The suffix of the individual names is added to the user defined Outlows name.  

             ".SWMM5_StorageVolume_CB.DAT"

             ".SWMM5_Runoff_CB.DAT");

             ".SWMM5_GroundwaterQ_CB.DAT"

             ".SWMM5_GroundwaterElevation_CB.DAT"

             ".SWMM5_NodeDepth_CB.DAT"

             ".SWMM5_NodeLateralQ_CB.DAT"

             ".SWMM5_LinkQ_CB.DAT"

             ".SWMM5_LinkVelocity_CB.DAT"

             ".SWMM5_LinkDepth_CB.DAT");

             ".SWMM5_XPSWMM_Runoff_CB.HIS"

             ".SWMM5_XPSWMM_Node_CB.HIS"

             ".SWMM5_XPSWMM_Link_CB.HIS"

Step 5.  Format of the files in XP-SWMM

ID  Number 140  Date/Time Value

pipe1    140.00199501010000     0.000

pipe1    140.00199501010001     0.000 

Step 6.  Use the files in XP-SWMM at a Runoff Node, HDR Node or Link

Step 7.  Format of the files in InfoSWMM

One line with ID followed by Date, Time and Value

Pipe06

01/01/2008 00:01:00     0.000 D

01/01/2008 00:02:00     0.000 D

01/01/2008 00:03:00     0.000 D

01/01/2008 00:04:00     0.000 D

01/01/2008 00:05:00     0.000 D

01/01/2008 00:06:00     0.000 D

Step 8.  Use the files in InfoSWMM

InfoSWMM Calibration Files

#RTFM and WTFM How to write a fine modeling manual worth reading (ideas)

Note:  The following is copied in part from this blog

https://opensource.com/business/15/5/write-better-docs

It is a wish list for me at least..

Types of docs

Once you've determined the scope, and who you're writing to, there are several different kinds of documents that you can write for them. Anne Gentle categorizes them like this:

Start here

Like the Getting Started document I mentioned previously, this is the place where you tell users what they need to know before they even get started.

Reference guide

The reference guide is comprehensive and usually pretty dry. This is where terms are defined, functions' input and output are explained, and examples are given. The tone is factual and to the point. There's not much discussion, or conversation. The voice is usually impersonal.

Tutorials

Tutorials hold your hand and lead you down the path. They show you each step, and occasionally sit down on a bench by the path to explain the rationale for a particular step. They are very conversational, sometimes even chatty. The voice is personal; you are speaking to a particular person, defined in the earlier persona phase.

Learning/understanding

Often linked to from the tutorials, the learning/understanding documents dig deeper. They investigate the why and the how of a particular thing. Why was a certain decision made? How was it implemented in the code? What does the future look like for this thing? How can you help create that future? These documents are sometimes better done as blog posts than as part of the formal documentation, as they can be a serious distraction to people that are just trying to solve a problem.

Cookbook/recipe

There's a reason that the Cookbooks are often the best selling part of the O'Reilly technical book catalog. People want solutions, and they want them now. The recipe, or cookbook section of your document, should provide cut-and-paste best-practice solutions to common problems. They should be accompanied by an explanation, but you should understand that most of the cookbook users will cut and paste the solution, and that'll be the end of it for them.

A large part of your audience only cares about solving their immediate problem, because that's all they're getting paid to do, and you need to understand that this is a perfectly legitimate need. When you assemble your new Ikea desk, you don't care why a particular screw size was selected, you just want the instructions, and you expect them to work.

So it's critical that examples have been tested. No matter how trivial an example is, you must test it and make sure it does the expected thing. Many frustrating hours have been spent trying to figure out why an example in the docs doesn't work, when a few minutes of testing would have revealed that a colon should have been a semicolon.

Recipes should also promote the best practice, not merely the simplest or fastest solution. And never tell them how not to do it, because they'll just cut and paste that, and then be in a worse fix than when they started.

One of my favorite websites is There, I Fixed It, which showcases the ingenuity of people who solve problems without giving much thought to the possible ramifications of their solution—they just want to solve the problem.

Error messages

Yes, error messages are documentation, too. Helpful error messages that actually point to the solution save countless hours of hunting and frustration.

Steps for Running RDII Analyst in H2OMap SWMM

Steps for Running RDII Analyst in H2OMap SWMM

Step 1.  Create the RTK UH in the H2OMap SWMM Attribute Browser (AB)

Step 2. Assign the RTK UH to a node (you need one node at least to Run RDII Analyst).

Step 3.  Open up RDII Analyst and Set up the Node for the Analysis

Step 4.  Select a Node

Step 5.  Define the Flow Data

Step 6.  Define the Rainfall Data

Step 7.  Calculate the DWF and GW flow

Step 8.  Calculate the Wet Weather flow – Flow minus Dry Weather Flow

Step 9.  Set up the RDII GA Run

Step 10.  The RDII Calibration Result

Step 11.  Export RTK parameters back to H2Omap SWMM

Runoff Surface Suggestions for Future #SWMM5 's and #SWMM6 - with added Emojis

Expanding Runoff Surface Types for Upcoming SWMM Versions 💧🌍🌆🌦

The Storm Water Management Model (SWMM) has been an instrumental tool in simulating urban hydrological processes. Over the years, SWMM has evolved, adding new features and capabilities 🚀. One area ripe for expansion is the classification of runoff surfaces 🌿🌃.

Current Runoff Surfaces in SWMM:

• Impervious with Depression Storage 🏢: Accounts for evaporation ☁ but not infiltration 🕳.
• Pervious 🌱: Considers depression storage, evaporation, infiltration, and potentially groundwater connection 🌊.
• Impervious without Depression Storage 🛣: Represents quick runoff from surfaces like roofs and gutters.

Enhancements in SWMM4 and SWMM5 introduced more intricate routing capabilities 🌐 and the integration of Low Impact Development (LID) methodologies 🌳🌼.

Proposed Enhancements for Future SWMM Iterations 🌟:

To reflect the complexity of urban terrains more accurately, there's a proposal to expand the number of runoff surfaces from the current 3 to a more comprehensive 12 📊. Each of these surfaces should have customizable properties, such as:

1. Flag for depression storage 🚩.
2. Flag for evaporation 🌬.
3. Flag for infiltration 🌀.
4. Flag for groundwater connection 🌍💧.
5. Flag for RDII (Rainfall-Dependent Infiltration/Inflow) 🌧⚡.
6. Flag for LID integration 🌸🏞.
7. Customizable widths and slopes 📏📐.

The existing SWMM framework provides a single slope and width for various runoff surfaces, which doesn't always mirror real-world scenarios. By allowing each surface to have distinct characteristics, it could enhance the model's accuracy and simplify the calibration process 🎯📉.

Technical Implications ⚙🖥:

Implementing these changes would entail:

• Adapting the SWMM 5 file import process to accommodate the expanded surfaces 📂.
• Modifying the Enums.h file to account for the new SubAreaType classifications 📑.
• Adjusting the runoff linkages in various modules, including Subcatch.C, RDII.C, Gwater.C, and LID.C 🔄🔧.

c
enum SubAreaType {
  IMPERV0,  // impervious surface without depression storage
  IMPERV1,  // impervious surface with depression storage
  PERV     // pervious surface
  // ... Additional surfaces can be added here
};

While these enhancements would certainly increase the model's complexity, the benefits in terms of accuracy and representation of real-world conditions could be invaluable for urban hydrologists and planners 🌆🌍🌧🌳.

#SWMM 5 LID 185 message

Here are the soil layer rules for LID’s in SWMM5....  If any of these are wrong you will get an Error 185 message

Soil Porosity > Field Capacity > Wilting Point

    //... check soil layer parameters

    if ( LidProcs[j].soil.thickness >= 0.0; 0.0 )

    {

        if ( LidProcs[j].soil.porosity      <= 0.0 

        ||   LidProcs[j].soil.fieldCap      >= LidProcs[j].soil.porosity

        ||   LidProcs[j].soil.wiltPoint    >= LidProcs[j].soil.fieldCap

        ||   LidProcs[j].soil.kSat            <= 0.0

        ||   LidProcs[j].soil.kSlope       <= 0.0 )

EPA is happy to announce the publication of Volume II of the #SWMM Reference Manual (Hydraulics)

Hello Everyone (from the @CHI SWMM List Server),

EPA is happy to announce the publication of Volume II of the SWMM Reference Manual (Hydraulics).  It can be viewed and downloaded from the EPA SWMM web page:
https://www.epa.gov/water-research/storm-water-management-model-swmm#documents

This completes the full set of reference manuals for SWMM 5 that also includes Volume I (Hydrology) and Volume III (Water Quality and LID).  We hope that these manuals allow SWMM users to gain a better understanding of the computational methods and techniques used by the program.

These volumes were completed by Dr. Lewis A. Rossman, EPA Emeritus.  In his extraordinary career, he has written three remarkable EPA public domain programs:  SWMM, the National Stormwater Calculator (https://www.epa.gov/water-research/national-stormwater-calculator which is based on SWMM),  and EPANET (https://www.epa.gov/water-research/epanet).   Since 2010, SWMM and EPANET have been downloaded at least 215,000 and 370,000 times and are the basis of many multi-billion, multi-year water infrastructure upgrades.  The codes are easy-to-use, relatively bug-free, and well-documented.  This last volume of the reference manual completes the documentation of SWMM.

Thanks, Lew, and thanks to all of you for your continued interest and support of SWMM.

Michelle Simon. Ph.D., P.E.
EPA Office of Research and Development
Water Systems Division
Associate Director of Science
Cincinnati, OH 45268

This is how node interface files works in #SWMM5, Caveats and Tips

The routine readNewIfaceValues reads a line interface flows in SWMM5.  It is a string parser, finds tokens and creates dates, times and flows from the tokens.  It is important to have the correct format for your line else the tokens will not be correctly converted to integers and doubles. Further, it is important to have more than one date/time for each node as the SWMM5 engine interpolates the flow values for each node during the simulation.  One time value or time values out of the simulation date/times will result in no flows.

void readNewIfaceValues()

//

//  Input:   none

//  Output:  none

//  Purpose: reads data from inflows interface file for next date.

//

{

    int    i, j;

    char*  s;

    int    yr = 0, mon = 0, day = 0,

                hr = 0, min = 0, sec = 0;   // year, month, day, hour, minute, second

    char   line[MAXLINE+1];            // line from interface file

    // --- read a line for each interface node

    NewIfaceDate = NO_DATE;

    for (i=0; i<NumIfaceNodes; i++)

    {

        if ( feof(Finflows.file) ) return;

        fgets(line, MAXLINE, Finflows.file);

        // --- parse date & time from line

        if ( strtok(line, SEPSTR) == NULL ) return;

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        yr  = atoi(s);

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        mon = atoi(s);

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        day = atoi(s);

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        hr  = atoi(s);

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        min = atoi(s);

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        sec = atoi(s);

        // --- parse flow value

        s = strtok(NULL, SEPSTR);

        if ( s == NULL ) return;

        NewIfaceValues[i][0] = atof(s) / Qcf[IfaceFlowUnits];

        // --- parse pollutant values

        for (j=1; j<=NumIfacePolluts; j++)

        {

            s = strtok(NULL, SEPSTR);

            if ( s == NULL ) return;

            NewIfaceValues[i][j] = atof(s);

        }

    }