SWMM-USERS Digest - 27 Mar 2012 to 30 Mar 2012 (#2012-30)
SWMM-USERS automatic digest system
Topics of the day:
1. Flooding discrepancies between graphs and attribute table (2)
2. Flooding discrepancies between graphs and attribute table (Out of Office )
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
----------------------------------------------------------------------
Date: Fri, 30 Mar 2012 15:58:49 +0000
From: Jason Barta <jba...@URBAN-SYSTEMS.COM>
Subject: Re: Flooding discrepancies between graphs and attribute table
My model had the option "allow ponding" deselected (not active).
I received the same results if I do allow ponding to occur at the nodes.
With respect to the time and reporting steps, I've set both down to 1 second and still do not see the flooding that appears in the table when viewing the graphs. Furthermore, the shape of the graphs do not suggest that there is the potential for a massive peak. For example, one node is 2.2 meters deep, yet the maximum depth only reaches 0.8 meters, concurrent with the most intense portion of the rain event. It reaches that peak steeply, but smoothly, suggesting that an even smaller time step and reporting period will still not yield the flood condition eluded to in the tables (no sudden spike in the graph).
Based on my observations, I will most likely proceed with accepting that any node with a flooding duration of 0.01 hours is most likely due to a mathematical instability, and will have to check the graphs for nodes with slightly longer flooding periods.
Thank you for all the suggestions and comments.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Robert Dickinson
Sent: March-27-12 5:45 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Hi Jason,
In addition to Greg and Joseph's comments
" Jason, also check the "positive value" for hours flooded. If it's a very small number (i.e. 0.01 hr equal to about 36 sec.) then it may be caused by a stability issue [I call it a burst of flooding]. In that case you may be able to discount/ignore it. I have seen some very short "bursts" of flooding and also they don't show up in the charts or the tables. I think in the .rpt file the Max values are a Max value for the "solution" tim estep...not the reporting time step. I think the charts and tables report the Max value for the reporting timestep. [or I might have that backwards]."
As Greg says if you have ponding allowed on then when it ponds the node will be listed as flooded even though no actual flooding occurs. As Joseph states the Max is the max of all of your time steps but the tables and graphs are reported at 5 minute time steps in your model. If you are using ponding allowed and a large ponding area the depth of flooding above the rim elevation may be small and not that noticeable when you graph it.
I hope these answers help.
Robert Dickinson
Innovyze Inc.
9340 Pontiac Drive Tel: 813-712-0664 Tampa, Florida USA 33626 robert.d...@innovyze.com www.innovyze.com
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Kacvinsky, Greg
Sent: Tuesday, March 27, 2012 1:07 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Is the model set up to allow ponding at individual nodes? If not, your HGL won't go above the rim elevation and your results will be misleading.
Greg
Gregory P. Kacvinsky, PE
Project Manager
OHM | Architects. Engineers. Planners.
34000 Plymouth Road
Livonia, MI 48150
p. 734.522.6711
f. 734.522.6427
d. 734.466.4476
m. 217.979.0422
Advancing Communities
This message, including attachments, is confidential and may be privileged. If you are not an intended recipient, please notify the sender then delete and destroy the original message and all copies. You should not copy, forward and/or disclose this message, in whole or in part, without permission of the sender.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Jason Barta
Sent: Tuesday, March 27, 2012 11:30 AM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
I have recently run a stormwater model for a 5 yr storm event over a 24 hour simulation period.
(5 minute time step and 15 minute reporting period)
My key interests are those nodes that are either flooded or show surcharging over the pipe.
Several nodes show a positive value for both "hours flooded" and "max. flood rate" in the node summary table.
However, when I look at the graphs of the depths at these nodes, they do not appear to flood based on depth graphed.
So I took the next obvious step and set the time step and reporting step all the way down to 1 second.
Still, the graph of the depth at the node showed no proximity to a flood condition, yet the table shows a positive number for hours flooded.
It seems like it could be a mathematical divergence of sorts.
My real issue is that this condition appears in approximately 50+ nodes in my regional model and I don't have the time, nor budget, to examine each and every node to see if the table results hold true. (imagine if 1000 nodes showed flooding...)
It would be most preferable to have the correct results shown in the tables, since I then export the tables out to GIS to prepare maps for the client.
Has anyone else seen this issue and know of a workaround other than examining each graph?
Thank you,
Jason Barta
Urban Systems Ltd.
Kelowna, BC, Canada
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
------------------------------
Date: Fri, 30 Mar 2012 10:23:47 -0700
From: "Pang, Joseph" <Josep...@SEATTLE.GOV>
Subject: Re: Flooding discrepancies between graphs and attribute table
Three things:
1. Have you input a non-zero size to your ponding area for the nodes? If you have not, then selecting "Allow Ponding" does nothing.
2. In the "Node Flooding Summary" part of the .rpt file, there is a "Time of Max Occurrence". If your report time step is at 1sec, go to the part of the simulation result indicated by the "Time of Max Occurrence" (the day since the start date of the simulation) and see what happened during those times at some of your flooded nodes.
3. If the "burst of flooding" are due to mathematical instability, try to lower your "Adjustment Factor" so that the hydraulic time step used internally by SWMM is sufficiently lower than that required by Courant Criteria to try to reduce instability.
Hope this helps.
Joseph Pang
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Jason Barta
Sent: Friday, March 30, 2012 8:59 AM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
My model had the option "allow ponding" deselected (not active).
I received the same results if I do allow ponding to occur at the nodes.
With respect to the time and reporting steps, I've set both down to 1 second and still do not see the flooding that appears in the table when viewing the graphs. Furthermore, the shape of the graphs do not suggest that there is the potential for a massive peak. For example, one node is 2.2 meters deep, yet the maximum depth only reaches 0.8 meters, concurrent with the most intense portion of the rain event. It reaches that peak steeply, but smoothly, suggesting that an even smaller time step and reporting period will still not yield the flood condition eluded to in the tables (no sudden spike in the graph).
Based on my observations, I will most likely proceed with accepting that any node with a flooding duration of 0.01 hours is most likely due to a mathematical instability, and will have to check the graphs for nodes with slightly longer flooding periods.
Thank you for all the suggestions and comments.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Robert Dickinson
Sent: March-27-12 5:45 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Hi Jason,
In addition to Greg and Joseph's comments
" Jason, also check the "positive value" for hours flooded. If it's a very small number (i.e. 0.01 hr equal to about 36 sec.) then it may be caused by a stability issue [I call it a burst of flooding]. In that case you may be able to discount/ignore it. I have seen some very short "bursts" of flooding and also they don't show up in the charts or the tables. I think in the .rpt file the Max values are a Max value for the "solution" tim estep...not the reporting time step. I think the charts and tables report the Max value for the reporting timestep. [or I might have that backwards]."
As Greg says if you have ponding allowed on then when it ponds the node will be listed as flooded even though no actual flooding occurs. As Joseph states the Max is the max of all of your time steps but the tables and graphs are reported at 5 minute time steps in your model. If you are using ponding allowed and a large ponding area the depth of flooding above the rim elevation may be small and not that noticeable when you graph it.
I hope these answers help.
Robert Dickinson
Innovyze Inc.
9340 Pontiac Drive Tel: 813-712-0664 Tampa, Florida USA 33626 robert.d...@innovyze.com www.innovyze.com
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Kacvinsky, Greg
Sent: Tuesday, March 27, 2012 1:07 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Is the model set up to allow ponding at individual nodes? If not, your HGL won't go above the rim elevation and your results will be misleading.
Greg
Gregory P. Kacvinsky, PE
Project Manager
OHM | Architects. Engineers. Planners.
34000 Plymouth Road
Livonia, MI 48150
p. 734.522.6711
f. 734.522.6427
d. 734.466.4476
m. 217.979.0422
Advancing Communities
This message, including attachments, is confidential and may be privileged. If you are not an intended recipient, please notify the sender then delete and destroy the original message and all copies. You should not copy, forward and/or disclose this message, in whole or in part, without permission of the sender.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Jason Barta
Sent: Tuesday, March 27, 2012 11:30 AM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
I have recently run a stormwater model for a 5 yr storm event over a 24 hour simulation period.
(5 minute time step and 15 minute reporting period)
My key interests are those nodes that are either flooded or show surcharging over the pipe.
Several nodes show a positive value for both "hours flooded" and "max. flood rate" in the node summary table.
However, when I look at the graphs of the depths at these nodes, they do not appear to flood based on depth graphed.
So I took the next obvious step and set the time step and reporting step all the way down to 1 second.
Still, the graph of the depth at the node showed no proximity to a flood condition, yet the table shows a positive number for hours flooded.
It seems like it could be a mathematical divergence of sorts.
My real issue is that this condition appears in approximately 50+ nodes in my regional model and I don't have the time, nor budget, to examine each and every node to see if the table results hold true. (imagine if 1000 nodes showed flooding...)
It would be most preferable to have the correct results shown in the tables, since I then export the tables out to GIS to prepare maps for the client.
Has anyone else seen this issue and know of a workaround other than examining each graph?
Thank you,
Jason Barta
Urban Systems Ltd.
Kelowna, BC, Canada
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
------------------------------
Date: Fri, 30 Mar 2012 13:24:11 -0400
From: Lisa Schaefer <Lisa.S...@DEP.STATE.NJ.US>
Subject: Re: Flooding discrepancies between graphs and attribute table (Out of Office )
I am out of the office this afternoon and will contact you upon my return. Please be advised the office is converting from a Group Wise client to Outlook this weekend. Outlook has certain limitations, which will be addressed. In the mean time, if your email contains attachments, please re-send them individually and indicate the full file name within the body of the message. I will have to rename them before I can open them.
Also, be advised there is a 20MB limit on any attachment. If your file is larger than that, you may have to zip the file and send it as compressed.
Thank you for your understanding in this period of transition.
>>> SWMM-USERS 03/30/12 13:23 >>>
Three things:
1. Have you input a non-zero size to your ponding area for the nodes? If you have not, then selecting "Allow Ponding" does nothing.
2. In the "Node Flooding Summary" part of the .rpt file, there is a "Time of Max Occurrence". If your report time step is at 1sec, go to the part of the simulation result indicated by the "Time of Max Occurrence" (the day since the start date of the simulation) and see what happened during those times at some of your flooded nodes.
3. If the "burst of flooding" are due to mathematical instability, try to lower your "Adjustment Factor" so that the hydraulic time step used internally by SWMM is sufficiently lower than that required by Courant Criteria to try to reduce instability.
Hope this helps.
Joseph Pang
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Jason Barta
Sent: Friday, March 30, 2012 8:59 AM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
My model had the option "allow ponding" deselected (not active).
I received the same results if I do allow ponding to occur at the nodes.
With respect to the time and reporting steps, I've set both down to 1 second and still do not see the flooding that appears in the table when viewing the graphs. Furthermore, the shape of the graphs do not suggest that there is the potential for a massive peak. For example, one node is 2.2 meters deep, yet the maximum depth only reaches 0.8 meters, concurrent with the most intense portion of the rain event. It reaches that peak steeply, but smoothly, suggesting that an even smaller time step and reporting period will still not yield the flood condition eluded to in the tables (no sudden spike in the graph).
Based on my observations, I will most likely proceed with accepting that any node with a flooding duration of 0.01 hours is most likely due to a mathematical instability, and will have to check the graphs for nodes with slightly longer flooding periods.
Thank you for all the suggestions and comments.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Robert Dickinson
Sent: March-27-12 5:45 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Hi Jason,
In addition to Greg and Joseph's comments
" Jason, also check the "positive value" for hours flooded. If it's a very small number (i.e. 0.01 hr equal to about 36 sec.) then it may be caused by a stability issue [I call it a burst of flooding]. In that case you may be able to discount/ignore it. I have seen some very short "bursts" of flooding and also they don't show up in the charts or the tables. I think in the .rpt file the Max values are a Max value for the "solution" tim estep...not the reporting time step. I think the charts and tables report the Max value for the reporting timestep. [or I might have that backwards]."
As Greg says if you have ponding allowed on then when it ponds the node will be listed as flooded even though no actual flooding occurs. As Joseph states the Max is the max of all of your time steps but the tables and graphs are reported at 5 minute time steps in your model. If you are using ponding allowed and a large ponding area the depth of flooding above the rim elevation may be small and not that noticeable when you graph it.
I hope these answers help.
Robert Dickinson
Innovyze Inc.
9340 Pontiac Drive Tel: 813-712-0664 Tampa, Florida USA 33626 robert.d...@innovyze.com www.innovyze.com
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Kacvinsky, Greg
Sent: Tuesday, March 27, 2012 1:07 PM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: Re: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
Is the model set up to allow ponding at individual nodes? If not, your HGL won't go above the rim elevation and your results will be misleading.
Greg
Gregory P. Kacvinsky, PE
Project Manager
OHM | Architects. Engineers. Planners.
34000 Plymouth Road
Livonia, MI 48150
p. 734.522.6711
f. 734.522.6427
d. 734.466.4476
m. 217.979.0422
Advancing Communities
This message, including attachments, is confidential and may be privileged. If you are not an intended recipient, please notify the sender then delete and destroy the original message and all copies. You should not copy, forward and/or disclose this message, in whole or in part, without permission of the sender.
-----Original Message-----
From: SWMM-USERS [mailto:SWMM-...@LISTSERV.UOGUELPH.CA] On Behalf Of Jason Barta
Sent: Tuesday, March 27, 2012 11:30 AM
To: SWMM-...@LISTSERV.UOGUELPH.CA
Subject: [SWMM-USERS] Flooding discrepancies between graphs and attribute table
I have recently run a stormwater model for a 5 yr storm event over a 24 hour simulation period.
(5 minute time step and 15 minute reporting period)
My key interests are those nodes that are either flooded or show surcharging over the pipe.
Several nodes show a positive value for both "hours flooded" and "max. flood rate" in the node summary table.
However, when I look at the graphs of the depths at these nodes, they do not appear to flood based on depth graphed.
So I took the next obvious step and set the time step and reporting step all the way down to 1 second.
Still, the graph of the depth at the node showed no proximity to a flood condition, yet the table shows a positive number for hours flooded.
It seems like it could be a mathematical divergence of sorts.
My real issue is that this condition appears in approximately 50+ nodes in my regional model and I don't have the time, nor budget, to examine each and every node to see if the table results hold true. (imagine if 1000 nodes showed flooding...)
It would be most preferable to have the correct results shown in the tables, since I then export the tables out to GIS to prepare maps for the client.
Has anyone else seen this issue and know of a workaround other than examining each graph?
Thank you,
Jason Barta
Urban Systems Ltd.
Kelowna, BC, Canada
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
Disclaimer :
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computers.
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
**********************************************************
* To sign off, email to: list...@listserv.uoguelph.ca *
* In the body of the message type: signoff swmm-users *
**********************************************************
------------------------------
End of SWMM-USERS Digest - 27 Mar 2012 to 30 Mar 2012 (#2012-30)
****************************************************************