Forum Replies Created
-
AuthorPosts
-
Luis PartidaParticipant
The first thing I would say is that velocities are determined via a calculated force and since it is not a tabular output currently, we have to use RAS Mapper to determine velocities. If I was modeling this and had this issue, I would adjust the internal XS manning’s n values to ridiculously high (0.5) and see if that stops it. This would then tell us that the velocity calculated is not out of a general range of expectations.
Is the bridge overtopping? In RAS versions 6.4 and earlier pressure flow was not capable of being calculated and that also may be the issue as those versions could only simulate low flow conditions. I would look into that by upgrading the model to V6.4.1.
There are so many things to look at here and hard to debug without the model in front of me. Here are some additional things to check
-Adding near repeats to your SAConn is also recommended by HEC.
-Make sure the “distance to the US XS” in the bridge editor falls within the first cell parallel to the bridge.
-Make sure the bridge is enforced correctly because that will cause odd results, i.e. NO crossing breaklines.
-Make sure the cells on the SAConn for your bridge are not drastically smaller than the global cell spacingHope any of this helps!
Luis PartidaParticipantI bet you have a red cell error that is not being shown in RAS Mapper. I still refuse to build out geometries in RAS Mapper as it is still buggy. Open the geometry data editor with RAS Mapper closed, then check the bottom left for a red message saying there is a cell with more than 8 sides and either fix it with a breakline or manual edit.
The other option I would suggest is to rebuild it again in a fresh environment and do not use RAS Mapper for anything
Luis PartidaParticipantHi Kendall, this website isn’t great when I have pasted links in the past. Google “modeling bridges inside 2D flow areas HEC” and a page should pop up where they go into great detail on what is going on with the entire process.
Luis PartidaParticipantHere you go
Luis PartidaParticipantI saw this question posed on reddit some time back and I think the user just deleted the BC line saved, closed re-poened and just drew it again and the error no longer popped up
Luis PartidaParticipantI will say this about this issue, while HEC intends to do away with the Geometry Data Editor, it is still by far the most stable environment to make model updates. I recommend not using RAS Mapper for mods like you explained.
Luis PartidaParticipantWhat version of RAS are you in. I am currently in V6.3.1 but maybe you are right, the model I am using uses constant and loss so i see many more variables. I wonder if SCS CN method you have to use computation outputs to view excess precip and compare it with your input and that would be your losses.
Luis PartidaParticipantIn RAS Mapper, right-click on your results plan and select “create a new results layer” then expand “additional 2D variables” this is where loss method outputs reside, hope this helps!
Luis PartidaParticipantI believe it is stated in RAS documentation that calculated WSE values as low as 0.01 are considered negligeable. That being said, if a target calibration of 0.05 cfs is desired, I would imagine RAS not being sensitive to roughness coefficients. Instead, what I would try is increasing or decreasing the # of XS’s in the model because the averaging between XS data will alter results but to the hundredth of a decimal place…I am not sure. Good luck
Luis PartidaParticipantI had a discussion with some colleagues regarding cupping specifically. Basically, that document was written prior to the release of HEC-RAS V6.2 which introduced a new render mode called Depth Weighted faces or “precip mode”. This render mode eliminates most issues related to cupping, so I would try this before any GIS related external mapping efforts.
Luis PartidaParticipantI would make a virtual clone of the terrain you have. Then recheck the elevations at the problem structures and I would even add a new modification on top of that modification. The next thing I would do is the basic dumb RAS debugs like save and close and reopen, disassociate that geometry with said terrain, save close reopen, rename the terrain save close and reopen, change the culvert invert to allow the model to work run it for a short duration and then go back and adjust back save close reopen…I know this isnt much help but we all know RAS is buggy as hell sometimes
Luis PartidaParticipantHEC intends to do away with the geometry data editor in the future and solely use RAS Mapper for everything, but, until that day comes, the Geometry Data Editor will always be more stable. That being said, I wouldnt focus on this that much.
Luis PartidaParticipantI am not sure why such a small grid size is needed and as a general rule of thumb, RAS models should try to stay under 1 million cells. There is not a limit documented but you might want to check where you are writing too and if you have enough disk space to handle it. Worst case scenario you handle the operation in ArcMap/Pro
Luis PartidaParticipantNo, dont do multiple meshes for each basin as the interconnectivity of them all would not only be a build, but a computational nightmare. Model it as a single subbasin in 1 mesh. In Harris County i believe for their modeling updates, placed hydrographs approximately 20-30% north of the subbasin outlet to not double account for time of concentration. BUT that rule worked well because delineation guidelines required subbasins around the 1-5 sq mile size. These methods were widely tested and documented in a series of white papers.
My suggestion is you go back to delineations and delineate to smaller areas giving you multiple hydrograph output locations then you can go back into a RAS domain, import your subbasin file as a map layer and then place your hydrographs as such.
Luis PartidaParticipantHey Scott, this is truly a great read and was well written by HEC to help best understand bridges in 2D modeling and what RAS is doing behind the scenes. I would give this a read.
-
AuthorPosts