Pages

Tuesday, March 24, 2020

The RAS Solution has moved to a new address

The RAS Solution is alive and well! It just moved to a different URL. If not automatically directed, please click here to get to the new and improved The RAS Solution.
https://www.kleinschmidtgroup.com/the-ras-solution/

Please update your bookmarks.

Happy HEC-RAS modeling!

-Chris

Thursday, February 13, 2020

Online Class - Using HEC-RAS to Modeling Bridges, Culverts, and Floodplains

Hey RAS Users-

This is a basic level steady flow HEC-RAS class.  That's right, we start from the very beginning with HEC-RAS-steady flow theory, building 1D geometry, steady flow boundary conditions, and even introductions to RAS Mapper and 2D modeling.  I'll be hosting weekly live sessions for this class to review the course material and workshops and for Q&A.

And it's an online course-that means you can take it from anywhere in the world-just need a computer with a wifi connection.

If you're relatively new the HEC-RAS, or just need a refresher, come and join me for this excellent intro class on HEC-RAS modeling.  Don't delay, there are limited seats. 









 
 
 

Monday, February 3, 2020

1D/2D Offline Connection Issues

Written by Chris Goodell | Kleinschmidt Associates
Copyright © The RAS Solution.  All rights reserved. 

I’ve mentioned this before, but I am thoroughly impressed with the robustness of the finite volume solution scheme used in 2D areas in HEC-RAS.  As long as your Courant Numbers are in a good spot, you rarely get errors and instabilities in 2D areas.  HOWEVER, the transition from 1D to 2D and back is another story.  In fact, the majority of errors I get in 1D/2D models occur there (either at the cross section to 2D area interface for inline connections, or in the cells adjacent to the lateral structure for offline connections).  In this post, I’m going to talk about the errors next to lateral structures at 1D/2D boundaries.

Take this for example.  The model runs well with friendly blue bars everywhere.  But I just can’t let go of the 5.154-ft error.  It only happens once and obviously doesn’t cause the model to crash.  But it’s there, and a 5-ft error is a little more than I can stomach. 

My usual go-to output for cross section errors, the water surface profile plot, gives me no clues as to what is wrong.  In RAS Mapper, I have what appears to be a flooded situation around the time where the error occurs, but reasonable looking results.  I turned on the Update per Screen option in the Velocity Layer Properties window, so that I could optimize the velocity scale for this view.  Here I noticed that the maximum velocity is 11.5 feet per second (fps) (which is about 3.5 meters per second).  This is way too high for this river, and in fact while hovering around the centerline of the river, I get maximum velocities of around 2.8 to 2.9 fps.  But since the Update per Screen option is turned on for velocity here, that indicates that there is a hotspot velocity of 11.5 fps somewhere in this view.  I just have to find it. 

On closer inspection, I can see some lighter shades of blue and green (i.e. higher velocities) in the floodplain adjacent to the lateral structures (as highlighted in the white circles).  Knowing that cells adjacent to lateral structures are typically going to be the culprits in 1D/2D models, I zoomed in to the cells around the lateral structures to get a closer look.  I started with the circled area to the right, since that was closest to the cross section that generated the numerical error of 5.154 ft.    



While zoomed in, it was hard to see at first, with the terrain turned on, so I turned off the terrain and noticed this little sliver of high velocity right at the boundary of the 1D river and the 2D area.


Turning the velocity off and the terrain back on, you can see how the 2D area dips into the main channel just slightly, and in fact it overlaps the lateral structure as well.  This reveals a very typical problem that you can run into with 1D/2D offline connections with lateral structures.  For a given timestep, RAS will compute a volume of water going over (or through in the case of gates and culverts) the lateral structure into a given cell.  But if the receiving cell has a small sliver of low lying area, like in this example, that relatively small amount of volume could be enough to significantly raise the water surface in the cell.  Perhaps enough so that it is even higher than the water surface adjacent to it in the 1D reach.  This would then send water back the other direction the next time step.  Besides the numerical shock of a sudden and large rise in stage, the oscillating effect of sending water back and forth can set up errors that persist, grow, and lead to an instability.

Now if you’re using the weir equation on the lateral structure, you could change your weir submergence decay exponent from the default value of 1 to 3 (1 is the most accurate, 3 is the most stable).  This has a dampening effect on the oscillations and errors you get from this situation.  Read more about the weir submergence decay exponent in the HEC-RAS User's Manual on page 8-41.  You might also reduce the weir coefficient.  This will reduce the volume of water that transfers from the river to the cell for a given timestep.  If there is no elevated feature represented by the lateral structure (e.g. it is not a levee), you would want to use a very low weir coefficient on the order of 0.1 to 0.5, as discussed in the 2D Modeling User's Manual on page 3-50.  However, in this case, it might be better to just use the 2D equations over the lateral structure instead of the weir equation.  Using the “Normal 2D Equation Domain” (this is just a funny way of saying “Use 2D Equations”) is a relatively new feature available in lateral structures.  But if your lateral structure does not represent an elevated terrain feature (e.g. a weir or levee), then this might be the better option to use. 



However, in recognizing that the 2D area perimeter and the lateral structure are poorly located, I will fix this first to see if that’s all that is needed to solve the problem. 
First, I’ll pull in the 2D area to just beyond the high ground.  This can easily be done in RAS Mapper on the 2D Area Perimeter Layer while in edit mode.  Next, I’ll pull over the lateral structure so that it resides ON the high ground. 


In the current version of HEC-RAS (as I type this post), Version 5.0.7, you cannot edit lateral structures in RAS Mapper.  So you have to do it in the Geometry Editor for now, using the Edit…Move Points/Objects command.  After moving the lateral structure, I adjusted the location of the 2D perimeter again, so it is just inside the lateral structure.  Here you can see a much better placement of both the 2D perimeter and lateral structure. 



And don’t forget, since I moved the lateral structure placement, I have to re-extract the terrain onto it.  Fortunately, HEC-RAS gives us a short cut to do this with the Terrain Profile button. 


After re-running, the error is gone and the results look much better.  Notice the peak velocity in the scale is back to a normal value of 2.6 fps.  And the 5.154-ft error is gone!





Monday, January 20, 2020

HEC-RAS Pub & Grub - HEC-RAS 5.1 and Beyond

Don't miss this great opportunity to listen to and interact with the HEC-RAS Developers in a fun and casual atmosphere!  Gary Brunner, Cameron Ackerman, and Mark Jensen will all be speaking at this Pub & Grub on Feb 20, 2020 from 5:30 pm to 8:30 pm in Portland Oregon.  They'll be covering all of the latest features being added to the upcoming Version 5.1 and beyond!  Show up, get some food, grab a pint and enjoy!

This is a free event, but we need you to sign up on our Eventbrite page so we can get a good head count.  Space is limited.  Hope to see you there!


Thanks to our Platinum sponsors Wolf Water Resources, Mead & Hunt, and Galileo and our Gold sponsors David Evans & Associates, OTAK, Geosyntec, and WEST Consultants.  Your generous contributions have made it possible to bring our guest speakers and provide the food.  A special thanks to the Craft Brew Alliance and pH Experiment for providing the awesome venue.