| Message/Author |
|
|
 Clare Cox posted on Thursday, September 15, 2005 - 08:52 am
|
|
|
| A quick question about flow inputs though - I was thinking about tom's method of just having a few inflow points. Tried it in my model and it works fine, the flow sorts itself out within a few cells. However, if these points are fixed, does this imply that the upstream cross-section is effectively frozen as the inflow cannot migrate in response to erosion/deposition? |
|
|
| Joe Wheaton
posted on Thursday, September 15, 2005 - 09:13 am
|
|
|
Regarding your question about flow inputs, I'm encouraged (but not surprised) to hear that you also find the flow sorts itself out within a few cells. The short answer to your question is yes. But I guess there are a few other points to consider:
First, if you're using Tom's 4-way routing scheme and you want to conserve mass, Tom suggested dumping the water one column in from the edge and use the edge cell's to build a dam (otherwise it might fall off the upstream bndy). I have some Matlab code that modifies the raster automatically for you somewhere if you'd like it (alternatively use Marco's raster edit). The dam insures you have a boundary condition that behaves like you expect it to (i.e. it flows down stream). Just dumping the flow in one cell as opposed to distributing it across the channel cross section means that you don't get yourself in a muddle over how to distribute the flow across that boundary (as in your current version). Just dump it sufficiently upstream of a section or anabranch that you care about.
The second point is an extension of the fist point... a boundary condition does not need to be on the boundary of the raster. In other words, you can dump the mass (water and/or sediment) in any damn cell you feel like it. In reach-mode CAESAR, you just give it a cell address and say how much you'd like to put there. Now, admittedly you usually dump this on the upstream edge of the reach and the grid is rotated so that you can calculate what flows off the right-hand-side. However, you can put it anywhere. I think Tom did this originally so that it was logically consistent with TRACER (correct me if I'm wrong Tom). That is you dump tagged sediment in a particular cell (typically mining waste, like tailings) at a certain rate that corresponds with the production of that waste and then it gets redistributed accordingly. You could use this to represent a pipe or culvert outlfow, or even a spring. In the current GUI you are limmited to only 4 or 5 cells you can dump the stuff in and you have to specify a configuration file for each (that is just a text file with a row for each time step and columns representing the water in-flow and sediment inflow (by size class.... i.e. your sedigraph and hydorgraph). Since most of your runs have been just water and steady-state simulations, you are able to get away in your code with one input file that tells you where to put it and how much to put there (you would need a 3 dimensional array to deal with dynamic situations in your case). In ooCAESAR, I've tried to make it more flexible by allowing you to specify dynamic boundary conditions at an unlimited number of cells.
Finally, on to your actual question... The short answer to your question was yes, the cross-section is effectively frozen. I would suggest that you probably should choose a relatively stable cross section as a boundary any way (or at lest not believe geomorphic changes of substance at the boundary)... but this is currently a limitation. There are lots of creative things you could potentially do to address this. You might try running a catchment simulation and pulling your left-hand-side (LHS) boundary condition of the reach-mode simulation wherever it ends up on the right hand side (RHS) of the catchment simulation. In a more flexible implementation of the boundary condition (dynamically) the input location could simply be allowed to move. Without the catchment simulation or field data, I don't see how you would have a rationale basis for specifying a dynamically located boundary condition, but in principle it would be relatively trivial to allow CAESAR to do this. |
|
|
| Clare Cox posted on Thursday, September 15, 2005 - 12:26 pm
|
|
|
Thanks for that Joe.
(To set the scene: I'm modelling a sub-section of a braided reach of the R Feshie at quite high resolution (1m grid cells)).
It does worry me that the dynamism of the section I'm modelling will be dependent on the patterns of change in the river as a whole - e.g. upstream inputs of sediment and flow distribution would depend not only on rainfall & catchment sediment supply, but also on patterns of avulsion & erosion in the upstream reach. So by freezing the upstream x-section, I would be artificially adding stability to the reach - or atleast the upper part of it. But without modelling a much larger reach, you're right I wouldn't have a basis for specifying how the boundary conditions would change and what flow should occur in what anabranch.
I guess the only answer to that is to model a larger reach.. |
|
|
| Tom posted on Friday, September 16, 2005 - 11:48 am
|
|
|
Hello Clare & Joe,
Joes right, in that the flow tends to sort itself out in the first few cells. There are (to be brutally honest) a couple of situations where this can give problems.
Firstly, if you add loads of sediment in at just one point (much too much) then it can just aggrade that one cell and not move to the downstream cells - it can create a mini fan or cone of sediment. You have to consider if this is the case whether or not this is or would be a realistic situation in the field - I suspect generally not!
One way around this is (for example) if inputting for a single channel reach is to spread the input over 4 cells - instead of just one cell at the input point. Effectively 'spreading the load'. There is of course no reason whatsoever why you cant get into the code and add more than 4 points - its all in an array that just needs the size increasing I think. 4 were chosen - as... I think because the mod was originally done to model the vale of York, where there were 4 inputs..
Another method to get around boundary issues is to
set the bedrock file to the same elevation as surface for the first few rows where material is input. This can prevent the other input problem whereby clear water causes too much erosion at the input point.. Thus you create a 'band' of the reach at the top that cannot change (well incise..) in effect making it like a flume.
Recirculating input - output points.. interesting and one that I have tried.. The problem is that if there is a sudden avulsion and the output channel shifts from the bottom to the top, then suddenly you change the input conditions dramatically - and this can have a feedback on the downstrream end etc.. it works better with a much longer reach, and I think that this mehtod was that used by Murray & Paola - but in their sims they tended to use long skinny reaches if I remember correctly..
Finally, your final point is correct Clare, you sometimes just need a longer reach!! or be prepared to sacrifice part of the top end.. or synthetically add a top part (at a coarser resolution??)
Hope this helps and that all is well,
Tom |
|
|
| Back to top |
|
