Weird results from Autodesk Storm and Sanitary Analysis (2014) 2

[fel3]

Greetings...

I was brought in late to a project to perform QA/QC reviews. The centerpiece of the project is a new oil-water separator (OWS) at an airfield. As part of this work, the project engineer built a model of the storm drainage system upstream of the proposed OWS using Autodesk Storm and Sanitary Analysis (2014). The watershed covers 22.5 acres and is divided up into 22 subbasins ranging from 0.32 ac to 4.93 ac. It's not a very big model.

The original model was based on the 2-yr event because that is the smallest "standard" event that exceeds the regulatory requirement for this particular installation and is what the client wanted us to design to. I reviewed the results from the original model and they looked good. The model matched the survey information, the rainfall data matched county requirements, etc. Using a couple programs I wrote years ago for my HP-42S calculator, I verified the peak runoff flow rate for each subbasin and verified the hydraulics for each pipe segment (all pipes were flowing partly full). I am fully satisfied it is a good model.

Then the client decided to change the design requirements and asked us to model the 10-yr event and design a bypass around the OWS to handle the excess flow. So, the project engineer replaced the 2-yr rainfall parameters with 10-yr rainfall parameters and re-ran the model. Herein lies the problem: some (but not all) of the results from the 10-yr run are downright weird. I spot checked subbasin peak flow rates and they look good. The total peak flow rate looks good. Some of the pipes in the system are now surcharged, which is to expected since it's a pretty flat site. The problem lies in the reported HGLs at inlets and manholes that are connected to the surcharged pipes. At more than a dozen inlets and manholes, HGLs are reported that exceed the elevation of the inlet grate or manhole lid by more than one foot to an astounding 619.82 feet. I'm not kidding. Somehow the model thinks I can stack water that high over a catch basin.

So now to my question: has anyone else encountered anything like our weird results when SD pipes get surcharged and, is there a solution? We are supposed to include these results in an updated tech memo on the subject, but I told the project manager it was a no-go until we resolve the weird results.

I did an internet search for bugs and problems with Autodesk Storm and Sanitary Analysis (2014) and came up empty. Maybe there is something out there and I didn't find it, but who knows. I have not run this particular software myself, but the project engineer has used it quite a bit and he had never seen anything like these weird results. If anyone is interested in helping me figure out what went wrong with the 10-yr model, I have attached an annotated copy of the printout for the 10-yr run and it includes a diagram of the system. On page 2 I have highlighted the highest inlet grate (elev. 16.50'), the lowest manhole rim (elev. 7.36'), and noted that the highest ground elevation on the rim of the watershed is about 17.6'. On page 14, I have highlighted the weird results. On page 16 I have highlighted the surcharged pipes.

Any help y'all can provide will be greatly appreciated. Thanks in advanve.

============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[fel3]

OK, so the file didn't upload and it didn't upload after editing. So, let's try this again.

============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[TerryScan]

I don't run this software, however, it would not be crazy to get wild results depending on how the model is set up. Typically, the model will extrapolate storage from the previous elevation stages. So, if the defined storage is ONLY the inlet (let's say a 4'x4'), the model would project the storage up a 4'x4' column when it exceeds the grate elevation. If the software allow defining actual surface storage above the grate, this will usually solve the issue.

Terry S

 

[fel3]

Terry...

Good idea and thanks. The project engineer defined surface storage ("ponded area"; see page 2), but it was only 10 sq ft at each inlet, probably just as a placeholder. I will ask him to increase this amount and see what it does to the HGLs.

Fred



============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[fel3]

Terry...

You were correct. The project engineer reran the model with ponded areas all being 10,000 sq ft instead of 10 sq ft and the Max HGLs dropped accordingly, back into non-weird territory. He is now using the topo survey to come up with reasonable estimates for the ponded area for each of the sub-watersheds.

Thanks again for your help and suggestion.

Fred

============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[gbam]

It has been some time since I ran this software, we use Bentley Storm & Sanitary now. I think they are the same. First off I believe the model is not dynamic, it will be steady state using the Rational Method. Please confirm this. If this is the case; one cannot "model" storage and attenuation using this model. The model is linear and will only compute headloss then add it to the EGL. It then subtracts Velocity head to compute the HGL; just math. The model; I presume, does not recognize the gates. That is for you to assess and adjust the design to mitigate the surcharge. Hope my interpretation is correct and it helps.

Forgot to add:
The solution is to upsize or add conveyance to the system to mitigate the surcharge.

 

[fel3]

gbam...

Thanks for the suggestion. However, Terry's suggestion got to the root of the problem.

Please note that my modeling expertise is water distribution systems and not so much storm drainage systems. In my 40+ year career I have done some small storm drainage models--the biggest being about twice as big as this one--but almost none in the last ten years and I have never used the AutoCAD model. That being said, the model is set up to use kinematic wave routing, which my research indicates is semi-dynamic, in that the software solves the model at a series of time steps, including the build-up of ponded water if appropriate, but assumes uniform flow in the pipes. With the ponded areas set to 10 sq ft, the water stacked dozens to hundreds of feet at some of the inlets. When the project engineer changed the ponded areas to an arbitrary 10,000 sq ft, the height of stacked water dropped proportionately (or nearly so...all I have right now is his word and I'm waiting on the final run based on realistic ponded areas).

Fred

============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[Kozzybear]

Great Post. I have ran into similar situations where I have a random node giving obviously wrong data. Glad you were able to solve it.

Curious as to the solution for running around the OWS. Are you guys proposing a larger structure designed for bypassing or a separate structure from the OWS entirely?

 

[fel3]

Kozzybear...

No, we're just adding a bypass pipeline around the new OWS to handle flows that exceed the capacity of the OWS. The regulators are fine with this because it will meet the permit requirements. In any event, the new facility will work a whole lot better than the existing facility, which is old, rickety, and poorly designed. Let's just say that the old facility and the permit requirements were sometimes at odds with each other.

The permit requires treatment up to a peak flow that is a bit less than the 2-year peak flow, but we designed the OWS for the 2-year peak flow plus a safety factor. The client had requested a safety factor for OWS capacity so we suggested 1.4x, which just happened to put us right at the capacity of one of the standard units produced by our project manager's manufacturer of choice (1500 gpm). It's amazing how that happens. However, because storm drainage flows can and will exceed the design capacity of the OWS, we need a bypass around the OWS. We suggested sizing the bypass for the difference between the 10-year storm and the capacity of the OWS, which the client agreed to. So, the OWS will handle flows up to 2-year + 40% and the bypass will handle the excess. Actually, the bypass will handle even more flow. We only needed a 24" bypass, but we're putting in a 30". The bypass is only about 50 feet long, so the cost difference is minimal.

So, what to do about flows that exceed the combined capacity of the OWS and bypass? Well, we simply forbid that from happening. In reality, the system will handle what it can handle, and at some point we will run into restrictions at the upstream catch basin grates, which we haven't analyzed. This is all black magic anyway, so it's good.

============
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill