2D Volume Errors at flows at and near overbank conditions

[Robert Holmes]

I have a 2D HEC-RAS 6.3.1 model which is displaying some unique volume accounting errors for particular flood profiles. The model is for a confidential client with the goals of 1) determining at what flood recurrence interval particular features along the riverbank become inundated, and 2) comparing the inundation extents at various locations along the modeled reach. The model uses 15-foot cell size for the channel and main area of interest and a 50-foot cell size for overbank areas upstream and downstream, with terrain data based on recent LiDAR. A detailed Manning’s n-value layer was developed for the channel and area of interest, and breaklines were added along channel banks, roads, and other high ground within the model area. The model applies an inflow hydrograph at the upstream end of the model and normal depth boundary conditions at all outflow locations; the hydrograph uses a constant peak flow hydrograph based on upstream gage data, with separate plans for each recurrence interval (1YR through 500YR). The model uses the SWE-ELM equation set with a 1-minute adaptive timestep based on the Courant number.
Interestingly, the model results show acceptable volume accounting errors (<1%) for smaller discharges (1YR-1.25YR) and higher discharges (20YR-500YR); however, for the 2YR, 5YR, and 10YR runs, the volume jumps to 9%, 4% and 2%, respectively. These are recurrence intervals of interest, as these discharges are where water starts to exit the channel and enter the floodplain. Notably, the high volume-accounting error is not accompanied by frequent runtime error messages. While some runtime errors are displayed, they are relatively small and infrequent; typically when I see a high volume-accounting error, there are several cells with very high errors that show up in the runtime messages. This is not the case here. Moreover, the Courant numbers throughout the simulation are very stable and almost universally less than 1. Again, I would expect to see high Courant numbers with such a high volume-accounting error.

I have tried numerous solutions to address the volume-accounting error. Initially, I thought the issue might be water slowly wetting cells in the floodplain. There is a diversion upstream of the area of interest which is not explicitly modeled, but which is reflected in the terrain data and which allows water to enter the diversion channel. The flow eventually reaches a small road crossing, backs up, and eventually overtops the ditch banks before slowly making its way downstream. My first suspicion was that the error was coming from dry cells in the overbank being wetted as this diverted flow slowly makes its way downstream. I modified the terrain to block the entrance to the diversion, and while this eliminated the inadvertent overbank flooding it did not affect the volume-accounting error. I also attempted cell and breakline edits to cells which did display runtime error messages to no effect.
Closer inspection of the error revealed that 1) the errors were producing a net increase in volume, such that the volume of water in the model at the conclusion of the model exceeded the difference between the inflow and outflow volumes, and 2) the errors are generally confined to the channel and are less than the tolerance proscribed in the model settings. The current theory is that repeated small errors in the channel (which are less than the tolerance set in the setting) occur repeatedly throughout the simulation. These errors are not enough to produce a runtime error message or trigger a change in timestep based on the Courant number, but due to the relatively small volume of the 2YR, 5YR, and 10YR discharges, cause the volume-accounting error to be high. If this is the case, it is unclear why the high volume accounting error is not present for the 1YR run.

Numerous fixes have been attempted to no avail: the hydrograph ramp-up period was increased from 1 hour to 12 hours (no change); the downstream boundary condition normal depth value was revised (no change); the simulation time was lengthened in the hope that the increase the amount of volume in the model would diminish the effect of the errors (some increase in error); further breakline and cell fixes were made in areas that did demonstrate runtime error messages (no change); the channel Manning’s n-value was decreased slightly (miniscule decrease in error) and increased slightly (very large increase in error); alternate equation sets were used (increase in run time but no change in error); and smaller WSE and volume tolerances were proscribed while also increasing the number of iterations (slight increase in error).

At present, the model is running with a very small timestep to see if that fixes the problem (increases the run time from about a day to a week or more). I am open to further suggestions of things to try to address the volume accounting errors for these runs. However, what I am really interested in at this point is if there is any justification for using the model results despite the high volume accounting error. Assuming the errors cannot be eliminated, I am curious if an argument can be made that the model still answers and effectively achieves the aforementioned goals despite the larger volume errors (e.g., “though the volume accounting error is high, the overall WSE errors are low, indicating that the calculated WSEs are still accurate,” or “despite the error, the inundation boundaries would not be expected to differ significantly because…”); or if the model cannot be relied upon in totality because of these issues. I am also interested if anyone else has experienced a similar error, where smaller and larger discharges perform fine, but those discharges which just begin to exit the banks cause problems.
I appreciate your thoughts on this matter.

• This topic was modified 1 year, 4 months ago by Robert Holmes.

[Luis Partida]

This seems very straightforward in that it is a time step vs cell size issue. I will say this, 15 ft cell sizes are typically never needed. To adhere to the courant conditions formula and just overall modeling guidance that scenario would require a very low computation interval and now your model takes 2 days to run (exaggeration). I would complete a cell size sensitivity analysis to see what you are gaining by using such small cell sizes then begin selecting an appropriate time step.

[Author]

Posts