SWMM 5.0.022, for LID_Type=PP, no soil layer on "Lid Control Editor"

SWMM 5.1.015 for LID_Type=PP, show soil layer on "Lid Control Editor", but, no save it on INP file. So, even if values are filled in on this screen, would it be being processed?

In the EPANET interface, curve-X[0] may not be 0, however it draws a curve. Here, it will be considered as a custom curve. Because?

if initlvl, minlvl, maxlvl are units dependet, why elev is not?

Is there a drawing with the dimensions of these sections?

Neyton,

wMax is the width at the widest point, which is 2/3 of the height (yFull) for Egg shaped conduits.

ywMax refers to the depth at which max width occurs. It is at 0.64 of the conduit height.

if wMax == 2/3 yFull, why ywMax != 2/3 ? 2/3=0.6666667 not 0.64

Would it be possible to modify the PID controller function and allow the user to provide lower/upper limits for the controller?

For executing multiple SWMM instances at once, it might be good to encapsulate these global variables in a struct so that difference SWMM instances do not conflict. I have done some work on this already (see https://github.com/HydroCouple/SWMM).

Can we look to expand the seasonal support for other object types other than subcatchments? I'm thinking in particular about modifying mannings roughness in conduits - primarily for the purpose of representing vegetation growth (or icing) in open channels during a continuous simulation.

This line can cause liquid runoff to occur even if temperatures are well below zero.  Can we add a check to make sure air temperature is above melt temperature? Would that be something like

if ( Temp.ta >= Snowmelt[k].tbase[i] )  ?

More info on our reasoning:

In a daily snow model we ran, low intensity snowfall falling when there was initially no snow depth resulted in snowpack depths at each timestep less than the 0.001 inches, and this line of code causes the low intensity snowfall to melt instantly - despite the temperature being -20 deg.C. 

The snowfall intensities were very low because we only had historical daily snowfall amounts, which convert to very small accumulated depths at small timesteps.

how to correct this error

????

If you are doing a culvert analysis for inlet control (that specifically uses this Arch shape, Corrugated Metal material, and Mitered to Slope inlet configuration) then note that the submerged c value should be 0.0473 (per Table A.2 in the FHWA Hydraulic Design of Highway Culverts - Third Edition) rather than 0.0463 as shown.

Date should be 03/14/17.

Runoff Surface Suggestions for Future #SWMM5 's and #SWMM6

As almost everyone knows about SWMM runoff surfaces there are three (non snowmelt) related surfaces in SWMM 1 to SWMM 5:

1. Impervious with depression storage, evaporation and no infiltration

2. Pervious with depression storage, evaporation, infiltration, with infiltration connecting to groundwater,

3. Impervious without depression storage, no infiltration, evaporation.  This was used to simulate fast runoff from gutters and roofs in the original SWMM 1.

SWMM4 and SWMM5 added pervious to impervious routing, impervious to pervious and Subcatchment to Subcatchment routing.  SWMM5 has further enhanced this feature by adding Low Impact Development (LID) for both pervious and impervious surfaces.  

Newer versions of SWMM should expand the number of runoff surfaces from 3 to 10 and make each Surface have a flag for depression storage, flag for evaporation, flag for infiltration, a flag for groundwater, a flag for RDII, a flag for LID's and the ability to have different Widths and Slopes for each surface.   The existing SWMM runoff surfaces have different Manning's n, different depression storages but share the same Slope and Width which complicates reality and makes calibration more difficult.

Coding wise this would mean:

1. Complicating the import process for SWMM 5 files (perhaps a global flag for number of surfaces)

2. Expand Enums.h for SubAreaType

3. Increase the complexity of runoff linkages in Subcatch.C, RDII.C, Gwater.C and LID.C 

enum  SubAreaType {

           IMPERV0,                         // impervious w/o depression storage

           IMPERV1,                         // impervious w/ depression storage

          PERV};                              // pervious

One small issue with the function of this routine is that it has to have more than one time value to work as the routine brackets the time between the new and old interface dates.  If the interface file runs out before the simulation ends or you have only time value there is not flow.  It might be better to have an option to keep using the last known flow and pollutants until the  end of the  simulation.  @rdickinson 

Cross referencing to a bug identified by Emnet

 https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/issues/61

Node Lateral Inflow Bug #61

a further note from Fred Myers

@dickinsonre The unneeded line of code is actually in node.c, within node_setOldHydState(). I only mention it because of your link to https://www.openswmm.org/SWMM51012/routing-c and I was wondering if there is one for node-c too.

The sequence of execution ended up performing these operations, though not all in the same routine:

1. Node[j].oldLatFlow = Node[j].newLatFlow;
2. Node[j].newLatFlow = 0.0;
3. Node[j].oldLatFlow = Node[j].newLatFlow;

Line 3 ends up always forcing Node[j].oldLatFlow to 0.0 rather than leaving it with the lateral inflow from the prior routing step. Removing the line in node.c: node_setOldHydState() allows oldLatFlow to retain the prior newLatFlow value.

I love the online code viewer online but it seems to be restricted to the SWMM5 engine code.  It might be nice to also see the Delphi Code or PAS code for SWMM5.

Shouldn't this be 5.1.009?   

Hello All, it would be nice if xsect.dat was shown in the list of files as well.

I copied this from the CHI SWMM 5.1.011 section I have been thinking of the general issue of dry weather flow patterns in SWMM5.  As you probably know the patterns are restricted to hourly patterns which is limited in this day of global sensing.  I did have a version of SWMM 5 that did have the option of having 5, 10. 15 and 30-minute patterns but this made for a messier looking inp file and GUI.

I think a better solution would be to add a new variable at the end of the time series line for a repeat option.  The repeat option would repeat the inflow time series for on day or set of days.  The advantage would be that the inflow time series can already have variable time step, it has a scaling factor.  I would then be easy to have 6 minute patterns for one day have those patterns repeated every day of the week.  New parameters are also better backwards compatible for older versions of SWMM5

addDryWeatherInflows is a flexible routine in SWMM5, it is called every internal but only calculates a hourly pattern for DWF at a node.  It should be simple to allow it to interpolate for minutes as well as hours.  The user can enter the time in minutes or hours which will allow the program to use non hourly patterns which has been long requested.  

The interpolation routine will have to altered to use minutes as well as hours from the parameter currentDate and the GUI will need to allow the reading, displaying and editing of more than 24 or 7 rows of data.  A Global Option should be used to allow the user to use interpolated patterns and constant patterns (the current default).

Everyone knows that SWMM only models the directly connected impervious area (DCIA) if would be nice now that the EPA has nicely structured the code to add at least two other runoff surfaces. For example, impervious surfaces that drain directly to pervious such as roofs to grass and the grassed previous area around a house that not only get directly rainfall but run-on from the rooftop.  It might be easier to calibrate rather than use the TO field in SwMM5 which sometimes causes confusion to new users.

enum  SubAreaType {
      IMPERV0,                         // impervious w/o depression storage
      IMPERV1,                         // impervious w/ depression storage
      PERV};                              // pervious
//   ImperToPerv;                 // For example, rooftop to grass
//   PervFromImperv;        // For example, Pervious area that gets runon from Rooftops

3rd part of making your own SWMM5 text file is to make the text file name = here is another section of text from iface.c where i pattern the new files on OUTFLOWS.TXT file

      case OUTFLOWS_FILE:
        if ( k != SAVE_FILE ) return error_setInpError(ERR_ITEMS, "");
        Foutflows.mode = k;
        sstrncpy(Foutflows.name, tok[2], MAXFNAME);
        // SWMM 5 Calibration File // QA/QC  RED - 2016
        sstrncpy(FcalibrationS.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationR.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationG.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationE.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationH.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationL.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationQ.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationV.name, tok[2], MAXFNAME);
        sstrncpy(FcalibrationD.name, tok[2], MAXFNAME);
         FcalibrationS.mode = k;
        FcalibrationR.mode = k;
        FcalibrationG.mode = k;
        FcalibrationE.mode = k;
        FcalibrationH.mode = k;
        FcalibrationL.mode = k;
        FcalibrationQ.mode = k;
        FcalibrationV.mode = k;
        FcalibrationD.mode = k;
        strcat(FcalibrationS.name,".SWMM5_S_CALIBRATION.DAT");
        strcat(FcalibrationR.name,".SWMM5_R_CALIBRATION.DAT");
        strcat(FcalibrationG.name,".SWMM5_G_CALIBRATION.DAT");
        strcat(FcalibrationE.name,".SWMM5_E_CALIBRATION.DAT");
        strcat(FcalibrationH.name,".SWMM5_H_CALIBRATION.DAT");
        strcat(FcalibrationL.name,".SWMM5_L_CALIBRATION.DAT");
        strcat(FcalibrationQ.name,".SWMM5_Q_CALIBRATION.DAT");
        strcat(FcalibrationV.name,".SWMM5_V_CALIBRATION.DAT");
        strcat(FcalibrationD.name,".SWMM5_D_CALIBRATION.DAT");
        break;

2nd part of new code example for adding your own text file output to SWMM 5 is the actual creation of the text file - i find it best to do this in iface.c and pattern the new text file on the existing outflows.txt file

void openFileForOutput()
//
//  Input:   none
//  Output:  none
//  Purpose: opens a routing interface file for writing.
//
{
    int i, n;

    // --- open the routing file for writing text
    Foutflows.file = fopen(Foutflows.name, "wt");
    FcalibrationS.file  = fopen(FcalibrationS.name, "wt");                        // QA/QC  RED 2016
    FcalibrationR.file = fopen(FcalibrationR.name, "wt");                        // QA/QC  RED 2016
    FcalibrationG.file = fopen(FcalibrationG.name, "wt");                        // QA/QC  RED 2016
    FcalibrationE.file = fopen(FcalibrationE.name, "wt");                        // QA/QC  RED 2016
    FcalibrationH.file = fopen(FcalibrationH.name, "wt");                        // QA/QC  RED 2016
    FcalibrationL.file = fopen(FcalibrationL.name, "wt");                        // QA/QC  RED 2016
    FcalibrationQ.file = fopen(FcalibrationQ.name, "wt");                        // QA/QC  RED 2016
    FcalibrationV.file = fopen(FcalibrationV.name, "wt");                        // QA/QC  RED 2016
    FcalibrationD.file = fopen(FcalibrationD.name, "wt");                        // QA/QC  RED 2016

I get a lot of questions from students who want to add a new custom output file to SWMM 5.  I find it best to use the nicely structured Lew Rossman code.  The 1st step to adding to output files is to add your new file names to global.h as in the following code example where i add new calibration files

EXTERN TFile
                  Finp,                     // Input file
                  Fout,                     // Output file
                  Frpt,                     // Report file
                  Fclimate,                 // Climate file
                  Frain,                    // Rainfall file
                  Frunoff,                  // Runoff file
                  Frdii,                    // RDII inflow file
                  Fhotstart1,               // Hot start input file
                  Fhotstart2,               // Hot start output file
                  Finflows,                 // Inflows routing file
                  Foutflows,                // Outflows routing file
                  FcalibrationS,          // Calibration file Innovyze RED 2016  // Storage Volume in a Storage Node
                  FcalibrationR,            // Calibration file Innovyze RED 2016   Runoff 
                  FcalibrationE,            // Calibration file Innovyze RED 2016   Groundwater Elevation
                  FcalibrationG,            // Calibration file Innovyze RED 2016   Groundwater Q
                  FcalibrationH,            // Calibration file Innovyze RED 2016   Node Depth
                  FcalibrationL,            // Calibration file Innovyze RED 2016   Node Lateral Q
                  FcalibrationQ,            // Calibration file Innovyze RED 2016  Link Q
                  FcalibrationV,            // Calibration file Innovyze RED 2016  Link V
                  FcalibrationD;            // Calibration file Innovyze RED 2016  Link D

An extra bit of run information I always like to see is the total number of steps - you can see this by adding the following line of code to report_writeSysStats

    fprintf(Frpt.file,
        "\n  Number of Steps             :  %7d",  StepCount);

I have been thinking of the general issue of dry weather flow patterns in SWMM5.  As you probably know the patterns are restricted to hourly patterns which is limited in this day of global sensing.  I did have a version of SWMM 5 that did have the option of having 5, 10. 15 and 30-minute patterns but this made for a messier looking inp file and GUI.

I think a better solution would be to add a new variable at the end of the time series line for a repeat option.  The repeat option would repeat the inflow time series for on day or set of days.  The advantage would be that the inflow time series can already have variable time step, it has a scaling factor.  I would then be easy to have 6 minute patterns for one day have those patterns repeated every day of the week.  New parameters are also better backwards compatible for older versions of SWMM5

is the rain garden computation includes in this function?

I got this error, I have checked and dates are correct? format etc are correct. 

any solution?

Bug: 

If you have “Skip Steady Flow Periods” checked and there are no events defined in the model, once the “InSteadyState” flag is turned on (TRUE), it doesn’t revert back again (FALSE).

The flag is evaluated after adding inflows to nodes, so it will remain on. Therefore, runoff won’t be added to nodes and no inflows are conveyed through the network.

I suggest to change this line to:

else for (p = 0; p < Nobjects[POLLUT]; p++) Node[j].newQual[p] = Node[j].OldQual[p]

This will avoid the discontinuity of node pollutant concentration when the node inflow is zero (specially important when there is water in the node).

maxinfil vol hasn't been updated yet

i don't think this is doing anything

infil model set in reading input file (infil_readParams)

get double stores values in second parameter (x[i])

Suggestion:

This line can be include between:

#ifdef WINDOWS

// here

#endif

How to solve this problem

A great view of the code.  It actually looks nicer than the way the code looks in Visual Studio.

Thanks,

Bob Dickinson

If drain delay is a non-zero value, it is added to the time at which rainfall ends. However, if drain delay is set to zero, drain outflow is not delayed at all and can start immediately, or at least before the time at which rainfall ends.

If drain delay is a non-zero value, it is added to the time at which rainfall ends. If drain delay is zero, drain outflow is not delayed at all and can start before the time at which rainfall ends. See barrelFluxRates() in lidproc.c.

This 4th parameter (drain delay) is used only for Rain Barrel type LIDs, but typically appears in the input file [LID Controls] section for all LID types, at it's default value of 6 hrs.

This 5th parameter is used only by the Swale LID type, but typically appears in the input file [LID Controls] section for all LID types, at its default value "5".

The elapsed time in detailed LID report time series is output here in minutes, whereas the header of the report file indicates units are hours. Either NewRunoffTime should be divided by 3600 instead of 60 to output elapsed time in hours, or the header should be changed to indicate minutes.

Elapsed time is actually output in units of minutes, not hours.

In "Open Channel Flow", F.M. Henderson cites Francis (1883) for flow over sharp-edged rectangular weirs, where the weir length is at least 3 times the depth of flow over the weir.

where

Leffective = Effective weir length
L = Actual weir length where L>3*h.
N = number of end contractions
h = depth of flow over weir crest

Possible bug:

This line prevents time series from being written to the second and all subsequent detailed LID reports. Changing ">=" to ">" should fix the issue.

“MC” and “KS” are used by SWMM instead of “Theta” and “KSat” as indicated in the EPA SWMM5 GUI. “KSat” still works as the program only looks for the first two letters “KS”, but "Theta" isn't recognized.