Stormwater-Management-Model
Stormwater-Management-Model copied to clipboard
USEPA
Out of Memory error In RDII.C if all R's are zero.
This is an engine error in SWMM 5.1.013 and earlier if the user has all zero R values for the RDII UH hydrolographs. The lack of ANY zero R should be an error message and trapped in the engine.
I could not reproduce this behavior for the following file (it ran successfully):
[TITLE]
;;Project Title/Notes
[OPTIONS]
;;Option Value
FLOW_UNITS CFS
INFILTRATION HORTON
FLOW_ROUTING STEADY
LINK_OFFSETS DEPTH
MIN_SLOPE 0
ALLOW_PONDING NO
SKIP_STEADY_STATE NO
START_DATE 06/07/2019
START_TIME 00:00:00
REPORT_START_DATE 06/07/2019
REPORT_START_TIME 00:00:00
END_DATE 06/07/2019
END_TIME 06:00:00
SWEEP_START 01/01
SWEEP_END 12/31
DRY_DAYS 0
REPORT_STEP 00:15:00
WET_STEP 00:05:00
DRY_STEP 01:00:00
ROUTING_STEP 0:00:30
RULE_STEP 00:00:00
INERTIAL_DAMPING PARTIAL
NORMAL_FLOW_LIMITED BOTH
FORCE_MAIN_EQUATION H-W
VARIABLE_STEP 0.75
LENGTHENING_STEP 0
MIN_SURFAREA 12.566
MAX_TRIALS 8
HEAD_TOLERANCE 0.005
SYS_FLOW_TOL 5
LAT_FLOW_TOL 5
MINIMUM_STEP 0.5
THREADS 1
[EVAPORATION]
;;Data Source Parameters
;;-------------- ----------------
CONSTANT 0.0
DRY_ONLY NO
[RAINGAGES]
;;Name Format Interval SCF Source
;;-------------- --------- ------ ------ ----------
1 INTENSITY 1:00 1.0 TIMESERIES 1
[JUNCTIONS]
;;Name Elevation MaxDepth InitDepth SurDepth Aponded
;;-------------- ---------- ---------- ---------- ---------- ----------
1 0 0 0 0 0
[OUTFALLS]
;;Name Elevation Type Stage Data Gated Route To
;;-------------- ---------- ---------- ---------------- -------- ----------------
2 0 FREE NO
[CONDUITS]
;;Name From Node To Node Length Roughness InOffset OutOffset InitFlow MaxFlow
;;-------------- ---------------- ---------------- ---------- ---------- ---------- ---------- ---------- ----------
1 1 2 400 0.01 0 0 0 0
[XSECTIONS]
;;Link Shape Geom1 Geom2 Geom3 Geom4 Barrels Culvert
;;-------------- ------------ ---------------- ---------- ---------- ---------- ---------- ----------
1 CIRCULAR 1 0 0 0 1
[HYDROGRAPHS]
;;Hydrograph Rain Gage/Month Response R T K Dmax Drecov Dinit
;;-------------- ---------------- -------- -------- -------- -------- -------- -------- --------
UH1 1
UH1 All Short 0 2 1 0 0 0
UH1 All Medium 0 6 2 0 0 0
UH1 All Long 0 12 3 0 0 0
[RDII]
;;Node Unit Hydrograph Sewer Area
;;-------------- ---------------- ----------
1 UH1 5
[TIMESERIES]
;;Name Date Time Value
;;-------------- ---------- ---------- ----------
1 0 1
1 2 1
1 3 1
1 4 0
[REPORT]
;;Reporting Options
SUBCATCHMENTS ALL
NODES ALL
LINKS ALL
[TAGS]
[MAP]
DIMENSIONS 0.000 0.000 10000.000 10000.000
Units None
[COORDINATES]
;;Node X-Coord Y-Coord
;;-------------- ------------------ ------------------
1 2356.495 7416.918
2 3776.435 6435.045
[VERTICES]
;;Link X-Coord Y-Coord
;;-------------- ------------------ ------------------
[SYMBOLS]
;;Gage X-Coord Y-Coord
;;-------------- ------------------ ------------------
1 830.816 8368.580
@LRossman your example works for me as well. I will post again the models that do not work for me here.
It was probably a stupid mistake on my part. I just made five models with the same R of zero and they all work. My apologies for making a spurious issue.
Hello, @LRossman Here is my test model that has the memory allocation issue. It is more complex than your example and does run with the RDII process flag turned off
ERROR 101: memory allocation error.
I put some debug statements into the code and ran the sewer_rdii_problem dataset. The issue seems to be an actual case of insufficient memory available to setup the RDII system for the 613 UHs in the example and has nothing to do with the R-factors being all zero. The memory issue is likely caused by the base duration of each long-term UH being 10,000 hrs (416 days), which is more than a year's response to a 1-minute rainfall (the wet time step). Each long-term UH requires an array of about 4.8 Mbytes to store previous responses for convolution purposes and there are 613 of these needed (my run crapped out at UH 348).
Thus I've concluded that this example is not evidence of a bug. It does however, suggest a couple of new features to add that might be useful. One obvious one is to have the program indicate which sub-system (in this case it's RDII) is causing an out of memory error. Another, specific to RDII, is to not allocate memory to the auxilary arrays used by a UH if its R-factor is 0.
Thanks, @LRossman I am trying to have extreme yet comprehensive examples of all of the very nice SWMM5 features. You are always great a debugging.
@dickinsonre and @lrossman, realizing this would potentially alter results, have you tried compiling with 64bit compiler? This would for sure solve this particular issue since the addressable memory space would be significantly greater. It seems like the appropriate direction to take SWMM. I believe we have a 64bit build process for windows at OWA SWMM. I feel strongly that we should move to 64bit builds/distribution. I think with all the new unit tests and reg tests online, porting could be a straightforward process. Do you all have any thoughts?
@bemcdonnell I just re-compiled the command line version of SWMM for 64-bits and the RDII example ran successfully. I agree that 64-bit is the future, but right now I simply want to fix the bugs listed in the Issues while keeping the engine compatible with the 32-bit Delphi GUI so that an updated version can be deployed ASAP.