Written by Daniela Todesco, P.E. | WEST Consultants
Copyright © The RAS Solution 2014. All rights reserved.
If you have built enough HEC-RAS models, you’ve probably discovered that having data in different vertical datums is a bit of a pain. RAS lets you adjust the vertical datum of individual cross sections (under “Geometric Data”, “Cross Section”, “Options”, “Adjust Elevations”) or portions of the model (“Geometric Data”, “Tools”, “Datum Adjustment”). However, I have to confess this: datum adjustments are always a little bit puzzling to me. I need pen and paper and a little numbering conversion to make sure that I’m doing things right when moving from one vertical datum to the next. And I recently had a “eureka” moment when I finally realized that the sentence “NAVD88 is higher than NGVD29 (for most of the locations we work on)” is actually wrong. Let me step back a moment and I’ll explain why.
The two most common vertical datums used in the U.S. are the North American Vertical Datum of 1988 (NAVD88) and the National Geodetic Vertical Datum of 1929 (NGVD29). NOAA’s VERTCON program can be used to compute the conversion factors from one datum to the other.
Tidal datums are, in general, confusing. Vertical elevations can refer to NAVD88, the station datum, Mean High Water, Mean Low Water, Mean Range of Tide, and a variety of other datums. In recent years, NOAA has been updating its reference tables with excellent graphs showing how the different datums relate to each other (like the one below for Astoria, OR - http://tidesandcurrents.noaa.gov/datums.html?id=9439040 -, where all elevations presented are related to the station datum, which is the Columbia River Datum or CRD).
Let’s say that you download data in the Astoria station datum and you want to convert the data in NAVD88. Since the NAVD88 datum is 2.02 ft above the station datum, you need to subtract 2.02 ft from the station datum to obtain elevations in NAVD88. Or, to make it easier to remember, if the data you obtain is in datum X and you want to convert it to datum Y, you need to ADD the vertical distance between the two datums if X is ABOVE Y (or SUBTRACT if X is below Y). In our case, X is the Astoria station datum, Y is NAVD88, X is below Y, and you subtract 2.02 ft to the Astoria datum to obtain elevations in NAVD88 (the distance between the two). Makes sense, right? This also explains why for most locations on the West Coast USA, the elevation in NAVD88 of a certain location is always higher than the elevation in NGVD29 of the same location (that’s because the NGVD29 datum is actually above the NAVD88 datum). For example, in Astoria, you need to subtract 3.4 ft to elevations in NAVD88 to obtain elevations in NGVD29.
Now, to confuse things even more, gage locations along the Columbia River follow an intrinsic datum that actually changes as you move upstream from the river’s mouth. For example, at Astoria, the station datum is BELOW NGVD29, while at Vancouver, the station datum is ABOVE NGVD29 (see graph below, at http://www.thsoa.org/hy05/09_1.pdf).
The USGS sent us a nice graph (see below) that helped me clear things up when reading datum-related station description information. This one is for the Columbia River at Vancouver gage in WA. The short station description reads: “Datum of gage: 1.82 ft above NGVD29”. The long version reads: “Datum of gage is Columbia River Datum (add 1.82 ft to correct to NGVD29)”. Remember: X is the station datum, Y is NGVD 29, X is ABOVE Y, so you need to add the distance to go from X to Y. To add something more to this graph, I would say that in CRD, the 0 of the NGVD29 datum is 1.82 ft below the 0 of the CDR datum, which reflects the previous graph. Hope this helps!
| What is being modeled with the Lateral Structure | Description | Range of Weir Coefficients |
| Levee/Roadway – 3 ft (1 meter) or higher above natural ground | Broad crested weir shape, flow over Levee/road acts like weir flow | US Units: 1.5 to 2.2 (2.0 default) SI Units: 0.83 to 1.2 (1.1 default) |
| Levee/Roadway – 1 to 3 ft (0.3 to 1.0 meter) elevated above ground | Broad crested weir shape, flow over levee/road acts like weir flow, but becomes submerged easily. | US Units: 1.0 to 2.0 SI Units: 0.55 to 1.1 |
| Natural high ground barrier – 1 to 3 ft (0.3 to 1.0 meter) high. | Does not really act like a weir, but must flow over high ground to get into 2D (or storage) area. | US Units: 0.5 to 1.0 SI Units: 0.28 to 0.55 |
| Non-elevated overbank terrain. Lateral Structure not elevated above ground | Overland flow escaping the main river. | US Units: 0.1 to 0.5 SI Units: 0.06 to 0.28 |
In order to do that, we need to delineate the storage area polygon, define new storage area connections, and generate lateral structures. The new “reach” (now a storage area) will look like the one below. 
Now we need station-elevation data for storage area connections and lateral structures. Easy, right? Well, not so fast. HEC-GeoRAS seems to have some issues exporting data when you take an existing project and try to modify shapefiles and extract data for only a portion of the entire model. It is especially difficult if you’re not the one who built the model in the first place. The shortcut is to think outside GeoRAS and obtain simple 3D station-elevation points directly from a TIN or grid for the storage area or structures you need. The bad part about that is that extracting tools in ArcGIS doesn’t really have an option to limit the number of points that are generated, and you end up with thousands of points that you can’t really use in HEC-RAS (the limit for cross section points, storage area connection weir/embankment points, and lateral structure weir points is 500). For example, in the connection called 83Coal in the figure above, I end up with over 2300 points. I’m stuck. Or so I thought… It turns out that RAS automatically “expands” its Station Elevation table to store however many points you need. In my case, 2339… 
HEC-RAS will still give you an error if you try to run the model with this data (the limit of 500 points still stands for computations!), but a simple click of the “Filter” button you see in the figure above solves the problem. Voila! Hope you liked this new (for me) discovery. 
Sometimes you can get your simulation to complete without crashing, but the listed numerical errors are so high that you can’t with good conscience submit that as your final simulation. Either way, approaching an unsteady HEC-RAS model (especially a dynamic one) as a beginner with little experience and understanding of how to stabilize it can cause significant delays in your project and worse, completely blow up your budget. I’ve uploaded two HEC-RAS projects to the following Google Drive Site: https://drive.google.com/folderview?id=0B_s8OLJOgOi0YU92SGZQZm9raWM&usp=sharing1. Cross Section Spacing. The initial spacing was way too coarse. A visual check alone of the geometry schematic and profile plot should encourage you to investigate a finer cross section spacing.
Geometry Schematic
Profile Plot Samuels equation suggests anywhere from 15 ft to 50 ft spacing (depending on what bed slope you use). I interpolated to 50 ft for the entire reach. http://hecrasmodel.blogspot.com/2008/12/samuels-equation-for-cross-section.html
Notice in the following profile plot of the downstream end of the reach how the water surface at the boundary cross section is below critical depth (the red dot). This creates an overestimation of the water depth at the next upstream cross section, which in turns creates some instability over the next several timesteps.
The proper way to handle this would be to find out what is downstream of your model and select a boundary condition that best represents those conditions. In absence of downstream conditions, the 0.001 slope for normal depth provides a reasonable solution. Either way, this underscores the importance of moving your downstream boundary far away from your area of interest in your study reach. That way the errors that do originate from your downstream boundary assumption will have diminished to negligible levels before impacting your area of interest.
I added more cross sections by interpolating the steep slope at the upstream end of the reservoir (10 ft spacing).
Notice the energy spike is not completely gone, but it is much better. Refining the HTAB parameters (http://hecrasmodel.blogspot.com/2009/02/crazy-energy-grade-line.html), turning on mixed flow and bumping up n values will collectively take care of the rest of this (see numbers 8, 9, and 10 below).
This is problematic in RAS. Using the graphical cross section editor, I redefined the bank stations to get rid of this problem.
I readjusted the cross section HTAB parameters to reflect the new bank station definitions (I used the “Copy Invert” button for all cross sections). While in there, I maximized the resolution of the HTAB parameters by changing number of points to 100 and minimizing the increment as much as possible while still having full coverage of each cross section. http://hecrasmodel.blogspot.com/2009/02/crazy-energy-grade-line.html http://hecrasmodel.blogspot.com/2011/03/more-on-htab-parameters.html
These are areas that are near critical depth. I turned on the “Mixed Flow” option in the Unsteady Flow Analysis window, which helps stabilize the near critical depths at the upstream end of the reservoir. http://hecrasmodel.blogspot.com/2011/04/mixed-flow-regime-options-lpi-method.html If you’ve been following along correcting your own copy of the model, you’ll notice that the model now finally runs to completion without crashing. There are still a few minor errors as shown in the Computation Messages.
It’s debatable whether you need to take care of these relatively small errors. Particularly for a dam breach model, where the presumed errors of the input data probably far outweigh these small numerical errors. Nevertheless, there’s a sense of pride in putting out a very robust model, completely free of numerical errors. So…let’s continue.
The section at the upstream end of the reservoir is very steep at about 13.5%. In fact, that’s greater than the suggested maximum slope of 10%, as stated in the HEC-RAS manuals. You can see as the pool starts to lower, the steep reach is exposed and because of the low n values, the water surface is calculated to be supercritical. Let’s assume that the geometry is correct, and the upstream end of the reservoir really is that steep. Jarrett’s Equation suggests very high n values should be used here (~0.2), based on the bed slope and hydraulic radius (after the breach when the reservoir has drained). The original model had 0.07 and 0.035 for the overbanks and main channel, respectively. I changed all the n values in this steep reach to 0.15, because I think 0.2 might be a little overkill. http://hecrasmodel.blogspot.com/2009/12/n-values-in-steep-streams.html
There…no errors! However, there is still a Warning about extrapolating above/beyond the rating curve at a bridge (R.S. 277).
There we have it. A clean solution. No errors, no warnings.
