Pages

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!





4 comments:

  1. Hi Chris

    I'm having this problem with version 5.0.7 where I get HDF error. This is relatively new. It's even happening on projects that I have previously successfully run. Is it possible updates to my machine might have caused this?
    What's the best way to fix it?


    hdf_error trying to use hdf output file subroutine hdf_q2d_write_real +time window: 30jan2020 2400 31jan2020; iter= 0

    ReplyDelete
  2. This may be an excessively large model in its current form. But another suggestion is to refine the mesh region adjacent to the cross section. If the LOB and ROB are connected to the same 2D mesh this can be done by simply drawing a full closed polygon around the region. If the LOB and ROB are NOT connected to the same region the mesh must be refined into 2 different override regions. You will notice once this is done the 1D connection to the 2D cell will be much closer in elevation then prior, this helps in the transfer of runoff from XS to cell. I understand your issue here, just giving alternative advice for anyone reading. Thanks!

    ReplyDelete
  3. What does it mean to use the 2D equation option when one side of the lateral structure is 1D cross-sections? Along the same lines, if there is a breach in the lateral structure, one must specify a breach weir coefficient. How is that weir coefficient reconciled with a selection of using the 2D equation to represent the lateral structure?

    ReplyDelete
    Replies
    1. It basically treats the lateral structure as if it were a series of cell faces, then it solves the 2D equations across those faces. The water surface elevation in the "cell" on the 1D side of the faces is determined by interpolation between the cross sections. If you use the 2D equations, instead of the weir equation, the weir coefficient is not used. 2D equation usually works better when there is a high degree of submergence on the weir, or if there is not weir at all. Weir equation usually works better when there is a defined elevated structure represented by the lateral structure (e.g. a levee or dike).

      Delete

Note: Only a member of this blog may post a comment.