[Scott Miller]

Thank you, Cameron. I am asking about confidence in that accuracy.

Installing a channel spanning box culvert where there is currently a constrictive squash pipe raises the 100-year flood elevation on a couple of residential properties by 0.02 foot. Regardless of diminutive height of this rise and immense benefits elsewhere, the regulatory requirement is zero rise.

We can and will come up with ways to abate that rise. But, really, could it be argued that there is no significant difference?

-update-

Of course, variations in mesh cell size should not yield different results for an accurate model.

[Scott Miller]

Thank you, Luis. It sounds like you were interested in WSELs at a timestep during the maximum elevation at a particular mesh cell. MAX is never going to be a single time step if the water flows at all. I am interested in determining the confidence with which I can know the WSELs at any particular mesh cell.

Let’s say two scenarios show a difference in elevation of 0.5 foot at a given mesh cell. I could go with that. But if the computation is only accurate to 0.05 foot for either scenario, then I only know that the difference in elevation is between 0.4 foot and 0.6 foot.

I am sure computation accuracy is going to be model specific. As long as everything else is held equal, model results for a variety computation point spacing and configurations could be fit to a distribution. Distributions could be developed for mesh cells in a variety of landscape conditions. Confidence intervals could be established for each. That kind of research is beyond the scope of this project.

I was asking about something more like a rule of thumb. For instance, the older lidar data I’m using has an error of about 0.1 foot in an open, flat field. That is the best precision I have when comparing different mesh cells (not accounting for error averaging/cancelling out).

[Scott Miller]

It is worthwhile to compare the performance of equation sets. I had stayed away from full momentum, expecting that it would take longer than dynamic wave. As it turns out, FM is more stable and simulates far faster for the geometries and topography in this model.

The stages in the above hydrographs are nearly the same between DW and FM. The culvert flow is more stable with the FM equation set.

I did some spot checks of maximum water surface elevations along the valley (downstream from this culvert), and, sure enough, the FM equation set consistently calculates higher water surface elevations. The difference is not alarming, tapering from 0.2 foot, in a broad, flat headwater area, to below 0.02 foot below a 2D bottleneck reach. I have to resolve the difference with the expectation that FM is more accurate than DW. Gauges wouldn’t help with this one.

Thanks so much!

[Scott Miller]

Here is a comparison of hydrographs at this low gradient culvert – full momentum vs. dynamic wave. The dynamic wave simulation took much longer to finish a 3-day period than full momentum took to finish a 10-day period. There is more instability at the culvert for the DW simulation, but I have to assume it did not play too much of a role in the difference in model speed. The DW simulation listed thousands of 1D/2D flow errors, albeit moderate, downstream. The FM simulation listed none.

Dynamic Wave

Full Momentum

It’s a 24-inch concrete pipe. Five feet of freeboard above the crown.

[Scott Miller]

Hi Ken. I did not put a gate in. The effect of valley storage affects downstream alternatives, and there is a back flow up to 4 cfs at this culvert at times.

I did make the mesh cells on either side of the connections much larger and tighten down the HTAB parameters – max. w.s. elevations. Then I focused on other things. (I did also specify the culvert center line after 5.0.4 came out.)

Going back to the connection hydrographs, and having run the model using full momentum, the flows and elevations are stable. Actually, developing a restart file using dynamic wave took longer to converge, and it may have been because of this culvert. I’ll test that.

So, I’ve got a question. Where did the dialog box (window) to set the maximum water surface elevations go?? I cannot find it in 5.0.5.

[Scott Miller]

Wiggling the ends worked… but it feels like a hack.

[Scott Miller]

1D/2D errors are normal. It is the flow that does not pass between the areas, and will cause a difference in water surface elevation. By default there are no iterations across the 1D/2D boundary. The magnitude of the flow error can be reduced by adding iterations. A threshold for acceptable flow error can also be set.

2D can be very slow. Provide more information about how your model is configured – maybe a detail of the geometry.

[Scott Miller]

You do not need to continue the property curve after it is fully wet (once it is fully wet it is a simple computation).

Of course, that ought to have been obvious.

The mesh cell that iterated a lot under full momentum is configured as you describe. Its downstream edge hangs across the edge of a headcut-like divot in the relatively steeper tributary. That can easily be fixed.

Regarding the land cover, there is quite a spread in values. I used Chow’s “normal” values for channel and floodplain. As the 2D calculations go, I figure there are flow rate differentials among pastured, mowed, and forested areas that simply iterate more to converge.

Thank you for pointing out the Courant map. It’ll be helpful for adjusting the time step control.

[Scott Miller]

Thank you Jarvus and Cameron. It looks like I could fine tune the Courant control and adjust the geometry or terrain to streamline the model.

I’d like to know how to identify cells that iterate the most. Maybe by reducing 2D iterations to the point that wse error warnings occur? Or maybe by switching to full momentum. I did switch from dynamic wave to full momentum and found a particular cell was problematic.

It is not clear exactly why that cell would cause problems, but, looking at the property/elevation plots nearby, it looks like the elevations may not be high enough. Is there a way in the 2D mesh to force the elevation range. Maybe the cells are too small (an attempt to limit Courant time step reduction in the tributary). Is there some way the depth on the property curve is projected from cell size and the topographical elevation range?

The variable time step is playing a part in the difference in model speed. I stopped the run described yesterday and removed the land cover. The model is running three times as fast. The first thing I noticed was that the time step did not drop to 0.5 second in the first few seconds of model time. It stayed at 1 second. I expect the uniform 0.06 Manning in the 2D flow area is subduing the Courant number somewhere.

Time could definitely be saved by lopping off the tail of the hydrograph recession and a trailing storm. It’s not necessary to model the subsequent period.

The number of math processors being used seems to be ok. Sixteen cores take 82% the amount of time eight cores do with this geometry (14,366 mesh cells).

[Scott Miller]

Running 5.0.5 now on 16 cores @ 2.3 GHz on Xeon (2.95 GHz actual). Previous attempts were 5.0.4 on 8 cores @ 3.6 GHz on Core i7, and a slower than real time on 4 core @ 2.7 GHz laptop Core i7.

The current model scenario without land cover Manning ran in 38 hours on the Xeon, and in 45 hours on the 8 core i7. At the rate the model is going at on the Xeon with land cover Manning, it will take more than 120 hours to complete four weeks of model time.

The 2D area is regularly iterating up to 4 times and the 1D reach regularly up to 2 times, with no 1D/2D flow error. This is low on a recession curve, though, and I expect it to iterate more intensively when the 100-year 4-day volume runs through.

I’m going to have to do the five scenarios without the land cover Manning. What opportunities are there to speed up the model, if I were to continue using land cover?

[Scott Miller]

Thank you, Jarvus. I was thinking the model might be better with the tributary modeled 1D, but it sounds like the 1D/1D confluence would have its own problems. I’m not familiar with it. It doesn’t sound like a geometry rebuild would be worth the time spent.

My understanding is that bridge and culvert modeling in 2D is not explicit as in 1D. I may need to look further into that, but it is part of why I kept the construction alternatives part of the model in 1D.

Overflow across the road goes into the tributary channel when the crossing/culvert does not have adequate capacity. While it would be straight forward to move the tributary hydrograph to 1D as a lateral inflow, I could not get rid of the lateral structure outright.

It seems, as Cameron may have been getting at, that the 1D/2D flow error may just be too high. This would explain why the WSE is so different between 2D and 1D at that particular lateral structure, at least when modeled with the weir equation. I’m not sure why the 1D gets superelevated when normal 2D equations are applied.

Rather than put the tributary hydrograph entirely into 1D, I’ll split it 50/50, maybe 67/33, and expect that that will balance flows over the lateral structure.

[Scott Miller]

Yes, Cameron, the lateral structures are iterating up to 20 times. The 1D/2D flow error is frequent during high flows. Most of the errors do not exceed the 20 cfs threshold by much, but there are numerous lateral structures. Next time I run the model I can look for what is happening at this particular lateral structure. The peak flow from the tributary is about 160 cfs.

A weir coefficient of 0.2 is applied.

The lateral structure where problems are occurring is 30 feet long, long enough to meet the high points abreast a constrained channel. I could shorten the lateral structure, but any break would be in the flow. Would that be a problem?

[Scott Miller]

It reads like you might have put elevations in manually. If so, there’s an easier way.

In the Lateral Structure Editor click the Terrain Profile button. Copy the table. Click the Weir/Embankment button. Use the copied table to fill out the Embankment Station/Elevation table.

More detail here: http://hec-ras-help.1091112.n5.nabble.com/1-2-D-Modeling-help-td5855.html#a5872

Also, ArcGIS (and likely other GIS) can be used to create the alignments and areas for RAS geometry. Make a polygon or line. Convert its vertices to points. Add X-Y coordinates to the points. Export the table in order to copy the X-Y coordinates.

For a centerline in RAS, paste the coordinates.

For 2D/SA, create a simple shape, open its editor, paste the copied coordinates in place of the simple shape coordinates.

[Scott Miller]

I take it you are using normal depth with an energy slope = 0.0091 as the downstream boundary condition. The errors you listed are a pair that come up together. Solving one ought to take care of the other. Check the number of iterations that are being used. It can be set as high as forty.

Take a look at where the energy equation is problematic. Is it at the stream crossing, or somewhere else?

Contraction and expansion around a stream crossings have to be handled a certain way. Take a look at this site: https://www.civilgeo.com/knowledge-base/hec-ras-culvert-cross-section-locations/

What does state or county code say, for guidance or requirements? Allowable headwater or required freeboard above the 100-year flow, aquatic organism passage, and other requirements may affect your sizing. How might beaver activity affect the crossing?

The approach you have taken appears to be reasonable, using a topographical quad map and interpolating cross-sections. At a mild slope I’d be looking at downstream controls to see if they affect the tailwater.

[Scott Miller]

Spruce Run, New Jersey , or Oregon, or somewhere else? Does pertinent code call for using HEC-RAS?

I wouldn’t recommend using Stream Stats unless the area was totally forested. And even if it’s a totally forested area, a regression model yields iffy results. The standard error on Stream Stats is usually fairly high. Be sure to account for it.

Are you modeling steady state? Peak flow is usually fleeting, so steady state does not make sense. Use a hydrograph, or a continuous model for the 100 year storm.

[Author]

Posts