Our peer-reviewed, open-access Journal of Water Management Modeling. Expand your knowledge, get insights and discover new approaches that let you work more effectively.
The International Conference on Water Management Modeling. Meet your colleagues, share your experiences and be on the forefront of advances in our profession.
The first DUMMY type conduit found will cause the loop to stop and no capacity limited checks will be performed for the remaining conduits. We think the “check only non-dummy conduit links” if statement should have a “continue” instead of “return”:
“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.
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
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.
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".
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.
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.
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 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.
Robert Dickinson
June 25, 2017
Do you have a way to combine all of this comments from a past to the current version of SWMM 5.1.012??
is the rain garden computation includes in this function?
Robert Dickinson
March 03, 2017
Yes, that is correct - BioCell and Rain Gardens use the same flux function
//... determine which flux rate function to use
switch (theLidProc->lidType)
{
case BIO_CELL:
case RAIN_GARDEN: fluxRates = &biocellFluxRates; break;
case GREEN_ROOF: fluxRates = &greenRoofFluxRates; break;
case INFIL_TRENCH: fluxRates = &trenchFluxRates; break;
case POROUS_PAVEMENT: fluxRates = &pavementFluxRates; break;
case RAIN_BARREL: fluxRates = &barrelFluxRates; break;
case ROOF_DISCON: fluxRates = &roofFluxRates; break;
case VEG_SWALE: fluxRates = &swaleFluxRates;
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
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 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
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
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
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
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).
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
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.
@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:
Node[j].oldLatFlow = Node[j].newLatFlow;
Node[j].newLatFlow = 0.0;
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.
Bryant McDonnell
July 24, 2017
I have fixed this bug - it's Here: https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/pull/62
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
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:
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.
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.
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.
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.
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)
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;
5.4. Fix one bug in gwater.c: set gw->evapLoss to 0 in gwater_initState() method to avoid unpredictable evaporation time series.
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.
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
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.
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.
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.
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).
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?
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"
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.
"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.
Code comments
Possible bug:
The first DUMMY type conduit found will cause the loop to stop and no capacity limited checks will be performed for the remaining conduits. We think the “check only non-dummy conduit links” if statement should have a “continue” instead of “return”:
if ( !isTrueConduit(j) ) continue;
“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.
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.
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
Elapsed time is actually output in units of minutes, not hours.
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.
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".
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.
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.
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.
A great view of the code. It actually looks nicer than the way the code looks in Visual Studio.
Thanks,
Bob Dickinson
How to solve this problem
Suggestion:
This line can be include between:
#ifdef WINDOWS
// here
#endif
get double stores values in second parameter (x[i])
infil model set in reading input file (infil_readParams)
maxinfil vol hasn't been updated yet
i don't think this is doing anything
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).
Hello Nandana, that seems like a good idea and it should be easy to test using a model with alternating wet and dry conditions in the node.
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.
Do you have a way to combine all of this comments from a past to the current version of SWMM 5.1.012??
I got this error, I have checked and dates are correct? format etc are correct.
any solution?
Can you post the Simulation Options section of your input file so we can review the date format?
is the rain garden computation includes in this function?
Yes, that is correct - BioCell and Rain Gardens use the same flux function
//... determine which flux rate function to use
switch (theLidProc->lidType)
{
case BIO_CELL:
case RAIN_GARDEN: fluxRates = &biocellFluxRates; break;
case GREEN_ROOF: fluxRates = &greenRoofFluxRates; break;
case INFIL_TRENCH: fluxRates = &trenchFluxRates; break;
case POROUS_PAVEMENT: fluxRates = &pavementFluxRates; break;
case RAIN_BARREL: fluxRates = &barrelFluxRates; break;
case ROOF_DISCON: fluxRates = &roofFluxRates; break;
case VEG_SWALE: fluxRates = &swaleFluxRates;
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
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 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
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
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;
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
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).
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
Hello All, it would be nice if xsect.dat was shown in the list of files as well.
Thanks for the suggestion Bob - its been added.
Shouldn't this be 5.1.009?
Currently OpenSWMM uses a 900 series point number to more clearly indicate it is not the official EPA SWMM5 engine.
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.
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:
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 have fixed this bug - it's Here: https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/pull/62
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
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:
Summary of changes
OpenSWMM5.1.907 includes the following enhancements to EPA SWMM 5.1.007:
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.
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.
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.
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.
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
2.2 Add w_SUBCATCHMENT constant to text.h
2.3 Add w_SUBCATCHMENT to OutfallTypeWords in keyword.c
2.4 Add InOutfall add Vrunon to TSubcatch in objects.h
2.5 Add TotalRunon to store total runon volume from outfalls (ft3) in globals.h
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).
5.3. Fix one bug in dynwave.c return should be continue in findLimitedLinks() method.
5.4. Fix one bug in gwater.c: set gw->evapLoss to 0 in gwater_initState() method to avoid unpredictable evaporation time series.
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.
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
Date should be 03/14/17.
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.
how to correct this error
????
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.
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.
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).
Would it be possible to modify the PID controller function and allow the user to provide lower/upper limits for the controller?
if wMax == 2/3 yFull, why ywMax != 2/3 ? 2/3=0.6666667 not 0.64
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.
Is there a drawing with the dimensions of these sections?
if initlvl, minlvl, maxlvl are units dependet, why elev is not?
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?
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?
cara mengatasinya ?
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"
If tok[0] == "NODESTATS", results k==5
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.
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.
Why here, elevation is not converted to feet??
If in EN_setnodevalue, is the value passed converted to feet?
Acredito que aqui deveria ser
elevation = elev / Ucf[ELEV]
I believe that here should be
elevation = elev / Ucf[ELEV]
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?
Gyyyyyyyyyy