|
From: Gareth D. <gar...@gm...> - 2019-06-20 03:35:43
|
Hi Kyle, My guess is that this model has too much numerical drag, caused by the fact that A) the channel is coarsely resolved, and B) the channel topography is natural, with shallowing towards the banks. At such coarse resolution this leads to shallow bank cells, which can be a substantial source of numerical drag (I have seen this in other models). If that's right, you might get substantial improvements by removing cross-channel variation in the elevation (only inside the channels of course!). Let the channels be essentially 1D, totally flat cross-channel. To do this, I would make an x/y/z dataset with the mean-channel elevation along the channels (lots of points, but 1-dimensional, going down the middle of the channel). Then also make a polygon defining the channel regions. Finally, set the elevation of points inside the channel polygon using some kind of smoothed nearest neighbours from the mid-channel point data. There are functions to help you do this kind of thing in anuga.utilities.quantity_setting_functions, in particular see composite_quantity_setting_function (which can take a set of datasets, each with a polygon defining where it is applied). That might well improve things. Good luck, G. What is the finest mesh size at which you have run the model? It looks like the code you sent uses 6000 (so triangles with roughly 100m side length), which might well be too coarse. On 20/6/19 11:36 am, Kyle A Wright wrote: > Hi Gareth, > > I can create a more quantitative plot with surface slopes through time > if that helps, but if you just want to see the time evolution of the > depth, I have the following GIF of depths through time (the color axis > was chopped to [0 1], but it shows the relevant problem clearly): > https://utexas.box.com/s/pbc46qvxcdctbdp0qos8us1ie2rq96fo > None of the channel banks north of the ~3,275,000 line should be > inundated at all. They aren't even normally inundated at twice this > discharge. > > Do you have specific recommendations as to what I could change about > the boundary conditions? The topography is identical to what others > have used in other models (Delft3D, XBeach) without experiencing this > problem. > > Thanks > - Kyle > > On Wed, Jun 19, 2019 at 8:04 PM Gareth Davies > <gar...@gm... <mailto:gar...@gm...>> wrote: > > Hi Kyle > > It might help if you can also send a plot showing time-series of > stage at a set of points along the channel (from right upstream, > through to the downstream tidal limit, at reasonably regular > intervals). Also, perhaps you could be more specific as to where > you think the "water spilling out" is unrealistic. > > **Is there a constant I'm unaware of in the code that I need to > change? What is the shallowest water surface slope that ANUGA can > simulate? I'm hoping this isn't a model compatibility issue, but > it seems like a possibility. ** > -- There is no "hard limit" to the slope that can be simulated. If > your results are convergent (i.e. not changing significantly under > mesh refinement) then I think it's not very likely that the > problem is due to limitations in the solver -- it's more likely > some issue with the topography or the manner in which boundary > conditions have been imposed. > > Cheers, > Gareth. > > > On 20/6/19 10:45 am, Kyle A Wright wrote: >> Hi all, >> >> I've been having a recurring problem with unrealistically high >> river stage values in the upstream portion of my domain. I've >> tried a number of things to fix this, but the end result is >> always the same: water spilling out of the channels in areas >> where it certainly doesn't spill out of at half-bankfull >> discharge. I've tried all of the things I can think of (as well >> as the suggestions from my previous email to the list-serve) to >> alleviate this issue and nothing has worked, so I'm hoping >> someone here might have some ideas. Is there a constant I'm >> unaware of in the code that I need to change? What is the >> shallowest water surface slope that ANUGA can simulate? I'm >> hoping this isn't a model compatibility issue, but it seems like >> a possibility. >> >> I've uploaded a simplified version of my code along with inputs >> in the zip file at this link, in case it is of interest to >> anybody: https://utexas.box.com/s/l1u01fgrtqjeqsjmi5pgde6c1ktmzczy >> It also contains a figure showing the stage issue. >> >> Below is a list of the things I've attempted to see if it would >> resolve this issue: >> 1) Different boundary conditions up and downstream (water does >> not appear to be building up in the model) >> 2) Clean breaklines in the mesh at the channel boundaries to >> reduce numerical drag >> 3) Increasing the grid resolution in and/or around the channel >> (down to grid sizes much finer than the "shallow-water" >> approximation should be valid) >> 4) Changing the vertical datum >> 5) Carving a deeper inlet and upstream channel >> 6) Artificially raising the banks in areas near the inlet to >> allow the flow directions to initialize before flowing into the >> relevant area of the domain >> 7) Starting from a fully dry bed >> 8) Starting from a static constant stage over inundated areas >> 9) Changing the flow algorithm to the least spatially diffusive >> 10) Storing cell vertices uniquely >> 11) Increasing the minimum_allowed_height >> 12) Changing the interpolation algorithm used to set the >> elevation of the cell centroids >> 13) Turning off all friction >> 14) Turning off channel friction with very high bank friction >> >> Any help would be greatly appreciated. >> >> Thanks and best regards, >> - Kyle Wright >> >> >> ---------------------------------------------------- >> On Mon, May 13, 2019 at 10:02 PM Gareth Davies >> <gar...@gm... <mailto:gar...@gm...>> >> wrote: >> >> Hi Kyle, >> >> Here are a few ideas to consider: >> >> Is there a growth in the downstream waterlevel over time, >> beyond what you would expect from the tides (e.g. maybe the >> dirichlet boundary is not allowing enough water to flow out >> of the model domain)? If that is the case, then you might try >> using a transmissive_n_momentum_zero_t_momentum_set_stage >> boundary in the downstream region. >> >> Otherwise, maybe your model has too much "numerical drag", >> even in the refined mesh test cases? In that case you might >> get better results by using breaklines in the mesh, so they >> follow the channels -- combined with setting elevation data >> at centroids, rather than vertices, so there is a clean >> discontinuity between the bank and the channel bed. This is >> good practice in general -- I've seen models with poorly >> resolved channels that were heavily affected by "bump banks" >> and associated numerical drag. The benefits of "cleanly >> defining" channels in the mesh can be large. >> >> You're right to also wonder about the flow algorithm being >> too diffusive. ANUGA type numerical methods are motivated by >> modelling flows with rapid spatial variations, shocks, etc, >> and they tend to bleed energy more than one might like for >> very quiescent subcritical flows. The latter can still be >> modelled, but it might demand more resolution than you'd >> like. The limiter could certainly play a part in that. You >> can check this by repeatedly refining the mesh -- if the >> result is not convergent, be suspicious. >> >> A few other things: You should probably test the "DE1" >> algorithm (it might be less diffusive than "DE0" which I >> think is the default); definitely double check your datum! >> Also, check if your upstream boundary realistic (i.e. is the >> lake level getting too high)? This might suggest a problem at >> that end of the model. >> >> Good luck, >> >> Gareth. >> >> >> On 14/5/19 11:31 am, Kyle A Wright wrote: >>> Hi all, >>> >>> I've been getting very unrealistically high depth/stage >>> values in the upstream end of my model domain, and I'm not >>> sure how to figure out what is causing it. >>> >>> Currently, my model is a river delta with one upstream >>> channel (constant discharge inlet + reflective BC inside an >>> upstream lake) and a downstream bay with a constant tidal >>> water level set by a nearby tide gauge (Dirichlet BC). Even >>> for flows significantly lower than bankfull discharge, the >>> water is spilling out of the channel and flooding the >>> surrounding landscape in places that definitely do not >>> normally flood. This happens even if I make the bed >>> completely frictionless, increase the grid resolution, or >>> start with different initial conditions. >>> >>> Is this something anybody else has experienced, and do you >>> have any ideas for how I might fix it? >>> >>> The only ideas I have left are that it is perhaps related to >>> (1) the datum (I am using NAVD88 in the vertical, which I >>> believe differs from the one assumed by the model, but I >>> wouldn't expect that to matter much over a few km), (2) >>> slope limiting (which I don't understand well, but it is a >>> very flat landscape), or (3) the flow algorithm (too >>> diffusive?). >>> >>> I've attached pictures of the depth and a quiver plot of the >>> flow velocities for context. Happy to send the code if helpful. >>> >>> Thanks & best regards, >>> -- Kyle >> >> This message is from an external sender. Learn more about why >> this matters. >> <https://ut.service-now.com/sp?id=kb_article&number=KB0011401> >> >> >> >> >> >> >> >> _______________________________________________ >> Anuga-user mailing list >> Anu...@li... <mailto:Anu...@li...> >> https://lists.sourceforge.net/lists/listinfo/anuga-user > > > > > -- > *----------------------------------------------------------------------------------------* > *Kyle Wright* > The University of Texas at Austin > Department of Environmental & Water Resources Engineering > (512) 712 - 8688 |