While doing some testing with SUDA on a previous project that was done in GEOPAK Drainage, I noticed that I was getting some abnormal large spreads for curb inlets in a sag. After I imported the .gdf file into a new file for SUDA testing, the spread was 10.12' while the spread in GEOPAK Drainage was 3.1138'. They should be somewhat close. Why is this??
One thing I did change in SUDA was in the inlet catalog, I changed the default curb opening length from 5 to 60 (60"=5'). Then I ran the computation again and it was somewhat close on the spread.
Maybe the program is figuring the curb opening length incorrectly?? Please look into this. Thanks.
Please share the model files for testing.
Sharing Hydraulic Model Files on the Haestad Forum
Bentley Technical Support
While we wait for a copy of the model file to confirm, here are a few possible factors involved:
1) Road and gutter cross slopes - can you confirm that they are the same between the two applications?
2) Differences in interpretation of HEC-22 between GEOPAK and the Haestad solvers. There are many gray areas in the HEC-22 inlet calculation standards, which can often account for differences in results. You can look at the StormCAD Help documentation for details on the equations used for curb inlets. Here are some examples which may or may not be involved in your particular case:
3) Version-specific problems. Based on the version number provided, I believe you are using a "SUDA" version that uses the V8i SELECTseries 5 version of the Haestad numerical solver. There is always the chance that some fixes and enhancements have been made in more recent versions. Do you have StormCAD to test this, or only SUDA? We can certainly test in the latest version (or in OpenRoads) once we have a copy of the model (.DGN file, for SUDA).
Jesse DringoliTechnical Support Manager, OpenFlows ProductsBentley Communities Site AdministratorBentley Systems, Inc.
Thank you for sharing your model DGN file. I was able to open it in Power GeoPak V8i (08.11.09.878). To test I ran the scenario "NW Base Analysis 2 year storm" wherein I got the spread for inlet DI 71 as 10.12 ft.
Since GeoPak uses storm-sewer models up to SS4 only, I had to convert your .stsw file linked to the DGN to the latest version of CivilStorm (10.01.00.72).
I then attached this .stsw to a blank DGN in Open Roads Designer. I analyzed the same scenario in SUDA but the spread value was same (10.12 ft). I am using Open Roads Designer (10.03.00.43).
So it seems that the HEC-22 equations are working similarly for both GeoPak and Open Roads Designer.
However I require the .gdf file for this project to open in GeoPak Drainage which you have not shared. To understand the difference in spread calculations please share the .gdf file.
Also please share the workflow you are adopting to open the file.
Additionally also share details about the scenario you tested, and the .stsw model.
The .gdf file should be out there now for you to look at. Basically I am just opening a file in PowerGEOPAK (08.11.09.893) and then opening GEOPAK Drainage to open up the .gdf for review. Nothing special with that.
Let me know if you have any other questions.
We're having some trouble opening the GDF file, but I'm not sure if we need it. See my previous post - it is very likely that the Haestad solver (used in SUDA/OpenRoads) has a different interpretation of HEC-22 in this specific case, yielding different results.
First, there appears to be a difference in input in the screenshot of the GEOPAK file, the SUDA model, and the model you sent. Here are some observations:
- In the GEOPAK screenshot, the Flow is 1.81 (CFS?) but in the SUDA screenshot and the model, the flow is 1.99 CFS
- In the GEOPAK screenshot, there appears to be a local depression of 3 inches with a depression width of 3 ft, in the SUDA screenshot it is 4 inches and 2 ft, and in the model file, there is no local depression.
- The "computed head" in the GEOPAK screenshot appears to be from HEC-22 equation 4-28 (I matched the result with a hand calculation)
- The depth (and thus spread) in the Haestad solver (and in SUDA) is a bit more complex, as explained in the forum discussion previously linked to.