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.
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.
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.
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
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
@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
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.
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
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?
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;
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??
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.
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
“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.
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”:
Code comments
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
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:
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
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?
Currently OpenSWMM uses a 900 series point number to more clearly indicate it is not the official EPA SWMM5 engine.
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.
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?
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 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?
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 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.
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.
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;