Gyyyyyyyyyy

Here, the value of "fraction" refers to a rate in percentage terms.

However, in the SWMM program, this value is expressed in lbs/ac or kg/ha.

Is this consistent?

I believe that here should be
elevation = elev / Ucf[ELEV]

Acredito que aqui deveria ser 
elevation = elev / Ucf[ELEV]

Why here, elevation is not converted to feet??
If in EN_setnodevalue, is the value passed converted to feet?

What if I want to add a head loss curve?

"int DLLEXPORT EN_setflowunits(EN_Project p, int units)" requires curve type to apply unit conversion factors, but curve type is only applied in functions: "int energydata(Project *pr)" sets to EFFIC_CURVE, "int valvedata(Project *pr)" sets to HLOSS_CURVE, "int updatepumpparams(Project *pr, int pumpindex)" sets to PUMP_CURVE, "int valvedata(Project *pr)" sets to HLOSS_CURVE. It is not clear the mechanism of loading an INP file.

Check this function as it returns incorrect values.
Example:
findmatch("NODE", ReportWords) returns 5
findmatch("NODESTATS", ReportWords) returns 5, when it should return 7
Note that the beginning of the word "NODESTATS" matches. So there are many chances of error in the code.

If tok[0] == "NODESTATS", results k==5

There is an error here.
If tok[0] == "NODESTATS"
Then
  k = (char)findmatch(tok[0], ReportWords);
  k will be equal to 5 because "NODESTASTS" starts with "NODE"

cara mengatasinya ?

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

OpenSWMM 5.1.907

Released February 23, 2015.

This is the source code viewer for OpenSWMM version 5.1.907, a public domain computational engine based on EPA SWMM5 version 5.1.007. It should produce almost* identical results to EPA SWMM5.1.007, provided none of the unique features of this engine are used (see Disclaimer below).

The purpose of the OpenSWMM engine is to:

• provide a method for adding community-generated improvements to the SWMM feature set,
• provide quality control and testing for community-generated SWMM code,
• provide an easier method for the US EPA to incorporate community-requested features into the official version of EPA SWMM, should they so choose, and
• provide a transparent, commentable source code repository to facilitate community education and engagement.

Summary of changes

OpenSWMM5.1.907 includes the following enhancements to EPA SWMM 5.1.007:

1. Multi-threading
   The dynamic wave routing method has been parallelized to reduce simulation run-time when using a multi-core CPU. This change does not affect the SWMM results, only the time required to produce them.
2. Outfall routing to subcatchments
   ​Outfalls have a new type that allows their outflow to freely discharge onto a user-specified subcatchment. Useful for modeling irrigation, piped discharge to LIDs and more. This change does not affect the SWMM results if not used.
3. Seasonal modeling
   Monthly time patterns can be applied to subcatchment pervious area attributes: roughness, depression storage and the Green-Ampt attributes. Useful for modeling infiltration changes due to frozen ground or seasonal runoff response changes in rural/agricultural subcatchments. This change does not affect the SWMM results if not used.
4. Conduit maximum volume statistics
   The maximum volume reached in each conduit during the simulation is now included in the Link Flow Summary table of the status report file. This change does not affect the SWMM results, only the report file structure.
5. Bug fixes in detailed LID reporting time series and elsewhere
   This includes four bug fixes - detailed LID reporting elapsed time is now output in units of hours instead of minutes, the issue of empty detailed LID report files has been addressed, checking of capacity limited conduits is corrected, and groundwater evaporation is initialized properly. These last two bug fixes may cause the OpenSWMM engine to produce different results from SWMM5.1.007 in some models.

Details

1. Multi-threading

SWMM's dynamic wave routing was parallelized using OpenMP parallel run (3 main loops)

1.1. Add parallel run support (OpenMP) to two methods in dynwave.c: findLinkFlows() and findNodeDepths()

1.2. Add parallel run support (OpenMP) to one method in stats.c: stats_updateFlowStats()

1.3 Modify methods in table.c to avoid racing condition (table_lookup(), table_lookupEx(), table_getSlope(), table_intervalLookup(), table_inverseLookup(), table_getMaxY(), table_getArea(), table_getInverseArea())

2. Outfall routing to subcatchments

Support a SUBCATCHMENT type of Outfall to route outfall outflow to a subcatchment as runon.

2.1 Add SUBCATCH_OUTFALL to OutfallType in enum.h

 enum OutfallType {
      FREE_OUTFALL,            // critical depth outfall condition
      NORMAL_OUTFALL,          // normal flow depth outfall condition
      FIXED_OUTFALL,           // fixed depth outfall condition
      TIDAL_OUTFALL,           // variable tidal stage outfall condition
      TIMESERIES_OUTFALL,      // variable time series outfall depth
      SUBCATCH_OUTFALL};       // sucatchment outfall              (OPENSWMM 5.1.907)

2.2 Add w_SUBCATCHMENT constant to text.h

#define  w_SUBCATCHMENT         "SUBCATCHMENT"                  // (OPENSWMM 5.1.907)

2.3 Add w_SUBCATCHMENT to OutfallTypeWords in keyword.c

char* OutfallTypeWords[]   = { w_FREE, w_NORMAL, w_FIXED, w_TIDAL,
                     w_TIMESERIES, w_SUBCATCHMENT, NULL};       // (OPENSWMM 5.1.907)

2.4 Add InOutfall add Vrunon to TSubcatch in objects.h

typedef struct
{
   ... ...
   int     inOutfall;    // inlet outfall                       // (OPENSWMM 5.1.907)
   double  Vrunon;       // runon volume from an outfall (ft3)  // (OPENSWMM 5.1.907)
}  TSubcatch;

2.5 Add TotalRunon to store total runon volume from outfalls (ft3) in globals.h

EXTERN double  TotalRunon;  // Total runon from outfalls        // (OPENSWMM 5.1.907)   

2.6 Set InOutfall to -1 and Vrunon to 0 in createObjects() method in project.c

2.7 Set TotalRunon to 0 in swmm_start() method in swmm5.c

2.8 Support new Outfall type in outfall_readParams() method in node.c

2.9 Support new Outfall type in outfall_setOutletDepth() method in node.c (same as Free outfall)

2.10 Add outfall outflow to subcatchment runon volume (add addOutfallRunon() method) in routing_execute() method in routing.c

2.11 Support runon from outfall in subcatch_getRunon() method in subcatch.c

2.12 Report Total Outfall Runon in report_writeRunoffError() method in report.c

2.13 Add total outfall runon in massbal_getRunoffError() in massbal.c

3. Seasonal modeling

Notes: There are variable name changes in TGrnAmpt in SWMM5.1.007

3.1 Add Seasonal.c and Seasonal.h to support seasonal modeling

3.2 Set currSub in subcatch_initState() and subcatch_getRunoff() method in subcatch.c

3.3 Support seasonal variables in grnampt_getSatInfil() method and grnampt_getUnsatInfil() method in infil.c

4. Conduit maximum volume statistics

Added Max Volume to Link Flow Summary report.

4.1 Add maxVolume to TLinkStats in objects.h

4.2 Initiate maxVolume in stats_open() method in stats.c

4.3 Update maxVolume in stats_updateLinkStats() method in stats.c

4.4 Report maxVolume in writeLinkFlows() method in statsrpt.c

5. Bug fixes in detailed LID reporting time series and elsewhere

5.1 Change Hours to Mins in initLidRptFile() method in lid.c

5.2 Change ">=" to ">" in lid_getRunoff() method's line:"while ( NewRunoffTime >= NextReportTime )", to allow all LID report files to be written (otherwise they contain headers only).

       for (j = 0; j < Nobjects[LINK]; j++)
       {
           // ---- check only non-dummy conduit links
           if ( !isTrueConduit(j) ) return;

Disclaimer

When not using the new seasonal modeling and outfall routing capabilities, this OpenSWMM engine should produce output and report files almost* identical to EPA SWMM5.1.007, warts and all. As such, this OpenSWMM engine is provided "as is", without warranty of any kind, and should not be construed as an endorsement or validation of the output of either version. The source code for this engine is provided and is eminently accessible - it is up to the user to satisfy him/herself that the code changes are correct for their needs and the output is useful. Neither CHI nor the individual authors involved accept liability for any direct or indirect loss arising out of its use.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

* Bug fixes 5.3 and 5.4 may cause OpenSWMM5.1.907 to produce different results from EPA SWMM5.1.007.

Terms of use

This is free and unencumbered software released into the public domain. Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

In jurisdictions that recognize copyright laws, the authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

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.