Jump to content
TUFLOW Forum
Meitzenk

simulation underestimates flood extent and depth

Recommended Posts

Hi,

I am modeling a large area 30,000 ha with 10m resolution using lidar and bathymetry survey for my terrain. I have two inflow points, one on the mainstem and one on a tributary, and one outflow on the mainstem below their confluence. I have mean daily data that includes discharge and stage data. I am using flow vs time on the upstream boundaries and flow vs water surface elevation on the downstream outflow boundary.

I have tried multiple different calibration scenarios with different time steps ranging from 2-5 and have modeled with varying rates on the time series data. The model runs fine and finishes without error, but it does not produce accurate results, and rarely even fills the channel with flow, much less the entire floodplain.

Over a single flood wave the stream flow may start at 90 cms and crest at 3336 cms and then wane back to 100 cfs all over a two week period. After I run the simulation, only the upstream and downstream ends of the model are inundated, and I can not seem to get the water to flow through the entire model and flood the floodplain. Where the model does convey overland flow it is very good, but it just does not propogate through the whole model. Each run takes about 5-7 hours.

The terrain data is very good, the floodplain is from a recent LiDAR flight and the bathymetry was stitched into the DEM from a field-based survey. I developed the terrain data in ArcGIS using a 4.5 meter grid, converted it to a TIN and then imported the 3d polygon/triangle faces into SMS as a scatter data set and created the TUFLOW grid from it using a 10 m cell size (i.e. analagous to the 4.5 m GIS raster format). So, I don not think it is a problem with my elevation data set, but instead my BC flow calibrations, parameters in the model control gui, and time step selection criteria.

I am using the TUFLOW model in SMS on a 64-bit OS with 8 Gb RAM processor.

Please advice.

Thanks you,

Kimberly

Share this post


Link to post
Share on other sites

Hi Kimberly,

If your DTM/bathy data is all good, and your material roughnesses are appropriate, but you aren't achieving the expected measure of flooding, then it would seem to me that you are underestimating your flows.

Applying a daily mean flow is going to smooth over the peak, so while the total volume of flow is (I assume) going to be the same, the actual peak flow trying to progress at once will be lower. The sharper your peak, the more this will impact results, so it may not be a particular issue for you given your event lasts two weeks. If you don't think that is likely to be the problem, then it may just be that your mean daily flow values are underestimated; possibly due to a gauge malfunction, or perhaps a rating that's not quite right at high flows, or or something else, depending upon how your flows were arrived at.

So, check your materials first, then your flow, and if you're very confident about both then I'm not sure where to go next! Thoughts from others?

Share this post


Link to post
Share on other sites

I think I agree with you PHA, the flows are the most likely cause. Particulary given that:

rarely even fills the channel with flow, much less the entire floodplain.

To me this suggests that the flow is drastically being underestimated. Futher to PHA comments, other things I would encourage you to check is that the units in the boundary condition are correct, these should be time in hours and flows in cubic metres per second (m<sup>3</sup>/s). Check also that the flow is being correctly inputted to the model, the easiest way to do this is extract flows using a Plot Output (2d_PO) line of Type Q_ (flow) immediately downstream of the flow boundaries. The total volume into the model (if the downstream boundary doesn't push water into the model) should match the total volume in your inflow hydrographs, check the mass balance (_MB.csv) files in the results directory.

Check the log file .tlf to ensure that the mass error in the model is acceptable (if the model was so unhealthy to lose as much volume as suggested I suspect the model would crash).

Let us know how you get on.

Cheers

Phillip

Share this post


Link to post
Share on other sites

Hi,

Thank you PHA and Phillip for your suggestions. I am going to include the peak Q for the event (as oppose to the daily mean for the crest), and I will reduce my floodplain manning's n roughness, right now it is mostly set for 0.1 for a forested landscape, the channel is set to 0.025.

My flow is in cubic meters per second and my terrain data is all in meters. So there is no problem there.

The log shows an outflow of 'zero' for most of the run time and it never matches the inflow... So there is most likely a problem with my BC flows.

I have another gage in the river between my upstream and downstream BC, so I am considering breaking my model into two sections...

I have run the same BC's through a 1D HEC RAS model and had no problems, but it was not a sophisticated enough model to show the complex overland flow, so that is why I am now modeling with tuflow.

I will report back after reducing the Manning's n and increasing the peak Q.

Thanks again,

Kimberly

Share this post


Link to post
Share on other sites

Hi,

I am still having difficulty calibrating the BC's for my model. The model is running fine, it just does not seem to have enough time or enough flow to fill the floodplain.

Can you provide and example of adequate time series and inflow for a large-area model?

Right now I am using mean daily data with peak flow data for the flood crest. The flood event spans 28 days, I am treating each day as an hour on the inflow, in the map out-put I am specifying an interval of 1800 seconds and on the Time, I am starting at 0 and running for 14 hours with a time step of 2.

Should I be duplicating my flows, or running multiple repetitions of the peak? Each model run takes about 8 hours cpu time. The ME% is less than 1%, it shows the correct amount entering the model, but only a fraction of flow exits the model.

Is there a rule relating inflow times to model size or model response time?

Please advise on tips/tricks for working with large models and coarse inflow data.

Thank you,

Kimberly

Share this post


Link to post
Share on other sites

Hi Kimberly,

You mention in your post the flood event spans 28 days but you are starting the model at 0 and running for 14 hours with a time step of 2. Is the problem that you are simply not running the model for long enough? The model start and end times are in hours (as you correctly identified), why are you running for only 14 hours? Should this not be 28 x 24 = 672 hours. Given that a 14 hour run takes 8 hours (and not much of the model is wet) you may need to look at increasing your cell size, otherwise your run may take weeks to finish.... The more cells that are wet in your model the slower the calculation (solving for more cells).

You may need to double your cell size (or more depending on the runtime you want). Double the cell size should results in an 8-fold decrease in the run times. By doubling the cell size, you have one quarter as many cells and the time step can also generally be doubled.

In terms of your inflows, is it possible to create a hydrologic model of the upstream catchment and use recorded rainfall and daily flows to calibrate?

It is very hard to use flows from one "large-area" catchment and apply to another, as the catchments are likely to have different areas, slopes, land-uses, rainfalls etc.

Cheers

Phillip

Share this post


Link to post
Share on other sites

Hi Kimberly,

If I understand your second post correctly, you are applying the mean daily flow for day one of your event to one hour of model time? Thus contracting your hydrograph by a factor of 24. If you consider the volumes passing into your model your flood wave would only contain 1/24 of the amount of water it should. This would explain why your floodplain is not filling up. The duration of high flow is every bit as important as the actual peak flow if there is any storage in the system (such as broad floodplains).

Unfortunately this may mean that you're looking at trying to run 14 days of modelling instead of 14 hours (I assume this is past the peak, and that's why your model was stopping then before?). This would, classically take about 24 times as long, so your run would take 8 days to complete instead of 8hours! To make this a bit more manageable then, you might like to consider (as Phillip suggests) increasing your cell size. With a 2x cell increase, you'd get the 8x speed-up Phillip talks of so a run time of just 1 day. Or if you were able to use cells 4x the size, you could get your runs down to only 3hours! But if you need the detail of the size you are currently using the you'll need to either use multiple domains, so you can use coarse cells where possible and detail only where necessary. Otherwise, breaking up your model into different portions might be a good option.

Let us know how you get on!

PHA.

Share this post


Link to post
Share on other sites

Hi,

I will try doubling my cell size (from 10m to 20m), and running the model for a longer period, with a longer time step (5). For my purposes, I mainly need the extent and depth at the peak of the flow, and do not necessarily need to model the falling limb of the flow.

Here is some context for my modeling:

The "large area" I am modeling is the actual floodplain. It is roughly 28 km long and 6 km wide. It has a very low slope 0.0002, and minimal cross-section variation in elevation (~3 m) the channel averages about 80 m wide and 3 m deep. My terrain data (Lidar DTM elevation points) has a spatial resolution of 1m and a vertical resolution of 15 cm, these data are have modeled as a TIN in SMS.

My goal is to model hydrologic connectivity between the mainstem river and the oxbows, hydrologic connectivity between oxbows, and flood depth associated with different geomorphic features, resulting from various high flow events. The floodplain contains about 100 abandoned meander channels. The flood plain inundates about 10 times a year, frequent smaller events inundate 20-50% of the floodplain and larger 1-yr recurrence events inundate 90% of the floodplain. It is part of an ecological study for Congaree National Park in South Carolina, USA.

I have chosen a new and different large magnitude flood event to model as a test. It starts at a flow of 92.63 cms for day 1 and increases to 3,031 cms over a 26 day period. I will set a run time for 624 hrs, with a time step of 5 (for the coarser 20 m grid), and output map intervals for 21600 secs (quarter day intervals).

Thank you all for your help, I will report back with my results in one to several days depending on run-time.

Regards,

Kimberly

Share this post


Link to post
Share on other sites

Hi,

I will try doubling my cell size (from 10m to 20m), and running the model for a longer period, with a longer time step (5). For my purposes, I mainly need the extent and depth at the peak of the flow, and do not necessarily need to model the falling limb of the flow.

Here is some context for my modeling:

The "large area" I am modeling is the actual floodplain. It is roughly 28 km long and 6 km wide. It has a very low slope 0.0002, and minimal cross-section variation in elevation (~3 m) the channel averages about 80 m wide and 3 m deep. My terrain data (Lidar DTM elevation points) has a spatial resolution of 1m and a vertical resolution of 15 cm, these data are have modeled as a TIN in SMS.

My goal is to model hydrologic connectivity between the mainstem river and the oxbows, hydrologic connectivity between oxbows, and flood depth associated with different geomorphic features, resulting from various high flow events. The floodplain contains about 100 abandoned meander channels. The flood plain inundates about 10 times a year, frequent smaller events inundate 20-50% of the floodplain and larger 1-yr recurrence events inundate 90% of the floodplain. It is part of an ecological study for Congaree National Park in South Carolina, USA.

I have chosen a new and different large magnitude flood event to model as a test. It starts at a flow of 92.63 cms for day 1 and increases to 3,031 cms over a 26 day period. I will set a run time for 624 hrs, with a time step of 5 (for the coarser 20 m grid), and output map intervals for 21600 secs (quarter day intervals).

Thank you all for your help, I will report back with my results in one to several days depending on run-time.

Regards,

Kimberly

Share this post


Link to post
Share on other sites

Hi,

Well, unfortunately, now that I increased my grid size from 10m to 20m I have problems with the terrain data, I am getting "unstable 2999" errors, in places that were previously fine. The error begins near my downstream BC and the flow circulates around a cluster of cells, slowly propagating the error. It includes both negative depth warnings and above my highest elevations warnings. The model eventually quits running on account of the instabilities.

This area in the 10m grid was working properly and it is not overly "bumpy". On the 20m grid terrain only varies from 23.09 - 22.69 - 23.3 - 24.2 accross the cells where this instabilities occurs. The instability starts one cell row above the lower downstream BC and the flow vectors show the flow reversing back upstream into the model as oppose to leaving it. Everywhere else the arrows are oriented downstream out of the lower BC area of the model.

I will try trimming the lower part of my active cells to avoid this area and re-run the model. I will also try using water surface elevation data and flow on the lower BC instead of computed water surface slope.

Any other suggestions?

On another note the channel is completely filled with water through the whole model and was beginning to backfill the smaller distributary channels as hypothesized. The longer runtime definitely solved that propblem, but unfortunately this new one has come up.

Thanks again,

Kimberly

Share this post


Link to post
Share on other sites

Hi Kimberley,

 

The most common cause of instabilities in the vicinity of a downstream boundary are:

 

1) An initial water level in the model different to the water level at the boundary at the first time step. This is more of an issue for Level-Time (HT) boundaries, rather than the Level-Flow (HQ) boundary that you are using. By specifying a water surface slope, TUFLOW is creating a stage-discharge relationship along this boundary.

 

2) A downstream boundary not digitised perpendicular to flow. Both HT and HQ boundaries set the water levels at all cells along these boundary to have the same water level. Care should be taken to ensure that cells along this location would normally have the same water surface elevation (i.e they are perpendicular to flow direction). I have attached a screen grab (skewed_HT.bmp) of a downstream boundary not perpendicular to flow direction. Changing the revised location in the same image fixed the instability issues at the boundary. Note it is generally preferable not to have right angles in the boundary, in this case i didn't have access to the DEM to suggest another location!

 

Forcing the water level boundaries in areas where you would expect variation along the boundary, can result in spurious circulations along the boundary which can result in the instabilities seen. If you step through the velocity vectors along the boundaries (you may have to exaggerate the scale) you can generally see areas of concern, the 2nd (perpendicular boundary) has a normal velocity pattern, the 3rd image (skewed boundary) shows a spurios circulation along boundary. In both of these images the vectors are very exaggerated (velocity magnitude is <0.05m/s). The other indication of the spurious circulations along the boundary are the oscillating Qo values in the log file (and DOS window), or Qo values on an incoming tide. This may be the reason you are seeing the reversing flows noted.

 

Lastly if the above to don't fix the issue, it maybe necessary to smooth the topography in the vicinity of the boundary. This is generally only necessary when a bumpy DEM is observed (e.g. LiDAR / ALS), a terrain modifier such as a zshape (2d_zsh) layer can be used to smooth out the topography.

 

Hope this helps.

 

Regards

Phillip

Skewed_HT.bmp

Perpendicular_HT_vectors.bmp

Skewed_HT_vectors.bmp

Share this post


Link to post
Share on other sites

Forcing the water level boundaries in areas where you would expect variation along the boundary, can result in spurious circulations along the boundary which can result in the instabilities seen. If you step through the velocity vectors along the boundaries (you may have to exaggerate the scale) you can generally see areas of concern, the 2nd (perpendicular boundary) has a normal velocity pattern, the 3rd image (skewed boundary) shows a spurios circulation along boundary. In both of these images the vectors are very exaggerated (velocity magnitude is <0.05m/s). The other indication of the spurious circulations along the boundary are the oscillating Qo values in the log file (and DOS window), or Qo values on an incoming tide. This may be the reason you are seeing the reversing flows noted.

Lastly if the above to don't fix the issue, it maybe necessary to smooth the topography in the vicinity of the boundary. This is generally only necessary when a bumpy DEM is observed (e.g. LiDAR / ALS), a terrain modifier such as a zshape (2d_zsh) layer can be used to smooth out the topography.

Hi,

Thank you this information is very helpful. I believe the problem is with my terrain data and the length/extent of my BC accross the floodplain valley. My situation seems to apply mostly the section I reserved in the quote above. And yes, the Qo values oscillated very high right before the instability occcurred. It seems from looking at the velocity vectors the instability was linked to smaller channels in the floodplain where flow was parallel to the boundary. I shortended the length of the vector where I apply the downstream BC to just extend perpendicualr accross the mainstem channel. So far it is running fine (59 hours into a 192 hr run), once it completes I will let you know how the run finishes.

Thank you for all your help.

-KM

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...