| Message/Author |
|
|
|
|
| This thread contains a list of code modifications made for verions 5.3 |
|
|
|
|
| Presently working on version 5.3p - getting the discharge proportions routed correctly - difficulties with discharge becoming unduly trapped in bends - influencing subsequent flow depth calcs. |
|
|
|
|
| 5.3r - may be an issue with flow being blocked from progressing if the three cells in front are higher than giving cell, this could be solved by expanding restrictions on discharged routed on to the full sweep width. |
|
|
|
|
| 5.3r seems to be working in conjunction with the "preventing flow being routed back in the same direction from which it came" routine added to the route_* functions. Now also seems to be working well with just 4 scans, instead of the 9. Possibly stopping the discharge from being sloshed around in bends/hollows generating excessive cumulative discharges |
|
|
|
|
5.3t - working much better, but also trying with not routing back on iteslf dependant on lat_vol as opposed to max_left, max_right etc..
Seems to work OK, but not performing 100% on lowmeander2.
Also tried uncommenting lines to stop it routing across the sweep width if the scan encounters too high a lat_vol (if lat_vol<q_out lines in route functions). This worked OK - which it has never done so before, but does result in rapidly fluctuating water discharges +-50%, so not perfect - may be worth further pursuing. |
|
|
|
|
5.3t, now restricing flow into 5 cells either side (as in comment above) instead of 3, maybee making things better -
Also tested without the pit filling algorith, included - It looks like it is probably required.. adding it stops there from being too deep |
|
|
|
|
Seems to work better with the pit filling routine added in.
Also works much betteer with the 5 cells to either side. But not with the section that prevents water being routed back against itself.. I am not sure that this section is really worth the added complexity.
Have also tried this with the lateral erosion routine. Seems to work OK, up to a point. THen lat breaks down. FOudn that this may be linked to ln 10515 where if(bedfraction<0.5)bedfraction=0.5; was commented out. This meant that the lateral slope (edge[,]) could drive sediment up a bank even if there was little down channel erosion deposition, which allowed constrictions to develop.
All this suggests that there should be a better method of calcualting Q within the channels.
At present Q is calculated using the discharge that is used to calc the largest depth. This is then stored in lat_vol[,]. A better way is required for calculating Q, and this will be pursued in the next step. |
|
|
|
|
New BUG/Error
This effects all previous versions, and concerns the input of suspended sediment when operating in reach mode. The volumes of sediment input at point sources from an input file will have been underestimated by a factor of DX*DX (where DX is grid cell size). This is a result of failing to convert from volumes to concentrations.
This can be fixed by altering Line 9762 and 9763 in erode() from:
tempsusp[x,y,n2,0] += amount_to_add;
tempsusptot[x,y] += amount_to_add;
to:
tempsusp[x,y,n2,0] += amount_to_add*(DX*DX);
tempsusptot[x,y] += amount_to_add*(DX*DX);
That should fix it! |
|
|
|
|
CAESAR notes - 10th June 2006-07-10
Tried various combinations to get discharge looking smooth, then out of randomness tried increasing the min_q to 0.1 for the lowmeander2 example, and this seemed to smooth things up dramatically. This reminded me of what Marco discovered, that you need to have a partial proportion of the flow being treated as ‘subsurface flow’ that is flow direction determined by bedslope alone. This seems to really tighten things up - and I may need to investigate this further,
Points to check/add:
Include discharges for bedslope flow in max_flow[x,y,1-8] so that they are included in the SS routing algorithms.
Need to Also disaggregate min_q for depth calcialtion from the proportion that should be treted as sub surface flow - could this be treated as a certain percentage of the flow - or possibly better scaled to grid cell size?
18th July
Version 5.3x
Disagg minQ from depth calculation worked OK - seems to be the best version running so far - tried it including lateral erosion with erosion based on Q, and this seemed to work quite well
5.3y
Trying with altering routing volumes according to slopes incliuding distance from the cell, instead of just the vertical elevation difference. Not especially happy with how it performs.. |
|
|
|
|
5.3y/z
Scrapped distance frmo slope cell as above - works better.
Found that was not incorporating width function into the bank erosion expressions - that lead to far more stable patterns. need to look carefully at how that is integtrated in to the lateral transfer of sediment part of erode_w, as this presently also scales (partly) to width - and this means that there is the potential for a positive feedback. Wider channels = lower lateral gradient = even wider channels, as there is less on the lateral gradient to push material to one side to make the smaller channel etc..
T |
|
|
|
|
5.3aa
Now working again on best ways to calculate discharge. If I count all the Q passing through all cells of a scan there are several methods..
1 total Qout in sweep direction for all cells and total leaving contributing cell
2 Total Q out in sweep direction for contributing cell and e.g. if lr, then ones to the left of the scan go into the up_out array and those to the right of the scan in to the down_out array.
3. combinations of the above but without adding the total
2 leaves a nice even distribution of Q across the channel
1 concentrates flow in the middle or edge.
using 3, tends to make the Q more realistic - ie lower.
not sure if 1 by concentrating flow is a realistic approximation or not. Will have to analyse the resutls more and think it through theoretically as well.
If anything 2 tends ot be too even and does not work especially well with the lateral component - that is it tends to damp it out.
Now, with all of the above, I have experimented with how to totup the Q. All the +ve values of leftout-rightout + upout-downout + rightout-leftout + downout+upout can be added - but tends to lead to much too large Q values
If you take the max value of leftout-rightout etc.. then that seems to give the best output.
Also experimented with scan directions. Now it is counting Q as the balance of flow from rl-lr or up-down etc.. It seems to be important that lr then rl then up then down
Tom |
|
|
|
|
5.3ab/ac
Found that there seems to be some importance in the amount of discharge left behind - or that routed according to bedslope not water surface to bed slope. Also in the routing section, found that where flow was routed to cells euther side or downstream the threshold that determined wheter it would or not was linked to MIN_Q, and it seemed to make a differernce.
However, then found that if erosion and depoisition rates were severely reduced, then there was a more even spread of discharge. I think this means that small scale (but large) fluctuations in shear stress calcs are leading to pits - that then are filled or released - instabilities, that are smoothed out when bedslope is used as the main driver.
Therefore am presently trying with smoothing Tau, but this presents problems of its own!!
T |
|
|
|
|
5.3ac
Yes, appears that small scale fluctuations in shear stress are leading to rapid development of pits/incorrect erosion and deposition. This can be fixed without the need for tau smoothing, if you re-introduce the line in calc_flowdirection() that prevents velocities being greater than those that give a froude# of > 1.
Still testing...
T |
|
|
|
|
5.3ad
Good grief.. all comes down to a coding error in adding up the discharges that are transmitted across the scan width.. problem was:
(i=n;i<x;i++) for one side and
(i=x;x<n;i++) was double counting on x, should have been
(i=n;i<x;i++) and
(i=n;i>x;i--)..
all seems fine now! Dont you just love computer models. WHeres the nearest bucket of sand to bury my head in!
T |
|
|
|
|
5.3ae
Now tried altering how k is calcualted in erode_w() which alters how tightly it deposits on the inside edge
ALso to get rid of scanning legacies, am presently smoothing the discharge remaining at the end of the scans, stops too much being concentrated at the edge of the channel.
Also, trying including or not including certain section that are included in left_out() series of arrays to improve accuracy of discharge calculation. May have to move to routing to cells in front as well as to one side though,,
Lateral erosion. To prevent square or diagonal meanders, included line in lateral2() that only allows 50% erosion rate for manhattan neighbours (I think). seems to fix it really nicely (well the erosion part!)
T |
|
|
|
|
5.3af
Gone back to checking for amount to be left behind (on a scan) to just being the three cells in front. Seems to make little difference - possibly better |
|
|
|
|
5.3aj
Found fault in the left_out[,] etc.. adding sections, was not accounting for Q sent to the diagonal neigbours (the ones at the end of the scan). As the code was, this would have made it much easier to deposit material on the inside of bends which is why the channels tended to narrow so nicely..
This seems to have tightened things up considerably. And things behave more sensibly.
Now trying to tighten up the deposition on the inside again - using k*3 in erode_w(). |
|
|
|
|
BUG/IMPROVEMENT - a generic one that applies to all previous CAESAR codes. For thos of you developing:
In the routing modules (route_lr(), route_up() etc..) replace the lines:
{
if(elev[x+1,y-1]<lowest)lowest=elev[x+1,y-1];
if(elev[x+1,y]<lowest)lowest=elev[x+1,y];
if(elev[x+1,y+1]<lowest)lowest=elev[x+1,y+1];
q_out = q_out * ((tot_ht - lowest) / depth[x, y]);
if(q_out>discharge[x,y])q_out=0; // line to prevent very very small depths increasing q_out disproportionaltely
if(lowest>tot_ht)q_out=0;
}
with
{
if(elev[x+1,y-1]<lowest)lowest=elev[x+1,y-1];
if(elev[x+1,y]<lowest)lowest=elev[x+1,y];
if(elev[x+1,y+1]<lowest)lowest=elev[x+1,y+1];
q_out = q_out * ((tot_ht - lowest) / water_depth[x, y]);
if(q_out>discharge[x,y])q_out=0; // line to prevent very very small depths increasing q_out disproportionaltely
if(lowest>tot_ht)q_out=0;
}
this means that the volume of water left behind in a cell (if the ones infront are too high) is divided by the max water depth calculated over all the previous scans rather than that scan itself.
Also note the line:
if(q_out>discharge[x,y])q_out=0; // line to prevent very very small depths increasing q_out disproportionaltely
Which is added from some previous versions. There is a post about this bug as well, but I thought it best to highlight it again. WHen operating in catchment mode, this could cause large Q volumes to erroneously enter the system |
|
|
|
|
Back working on the lateral erosion again..
three improvements/things to note..
1. There were problems with having outside edge bends dominate on straight sections, which made the channel want to perpetually widen. This can be resolived by multiplingn inside edge values by 1.1 or 1.2 which increases their dominance. This means that straight sections tend to have zero to inside bend gradients
2. Now trying without water surface smoothing - seems to solve alot of problems actually, with the lateral erosion. Will advise more later
3. When running without water surface smoothing, you can then use the line which reduces velocities when the froude # is > 1. (in Calc_flow_direction()). This means that you do not get siuch high shear stress values on the inside edge of bends. Which in turn means that they fillup quite nicely as the meander progesses outwards.
Strange how adding all these fancy new things (smoothing etc,.) can sometimes seem to make it work worse! |
|
|
|
|
| Running well without water surface smoothing, bed elevations adjust nicely in order to accomodate. |
|
|
|
|
Update on recent developments:
Summary of much of the above. Now found that using velocities to calculate Tau seems much more stable.
However, need to have a high 'lateral' gradient in order to drive desposition on the inside of bends. As the other proportion of bed material is routed according to bedslope, this means that bedslope is generally fighting against the lateral slope - which is why it has to be so high.
Also, found some problems in longer term runs, esp on the lower gradient severn runs, where sediment just accumulated behind a point - resulting in backingup of sediment. This is because whilst erosion (Tau) is controlled by discharge, the distribution is controlled by local gradient. THe two are related, but previously low gradients would have led to low Taus so no erosion. Similarly at the nose of one of these areas of deposition, there would (using bedslope to calc Tau) be a local high of Tau, causing more erosion. With Tau calced by Q/v this does not necessarily happen all the time.
So, to try not to mix apples and oranges, in what was determining how much sediment was eroded, as well as where it went to, I have tried routing water according to the discharges in different directions. In erode_w() instead of using bed-slope use the balance of dishcharge in all directions.
This created a whole series of interesting phenomena. It led to massive flow concentration, so that flow tended (strongly) to form into one single channel. This was wella nd good in meandering/lowland applications, but not so for braided rivers - which I would still like to be able to model! |
|
|
|
|
5.3ay
Found a link when using discharge to determine Tau, in that:
The level that the pits are filled up by should be linked to the erode_limit variable. This means that the model cannot erode the bed faster than the pit filling can fill it in,
Otherwise, you can develop an increasing pit, that draws in more discharge - causing it to increase in depth etc..
Tom |
|
|
|
|
version 5.3ay
Regarding post on Friday, September 29, 2006 - 02:30 pm
<quote>2. Now trying without water surface smoothing - seems to solve alot of problems actually, with the lateral erosion. Will advise more later
3. When running without water surface smoothing, you can then use the line which reduces velocities when the froude # is > 1. (in Calc_flow_direction()). This means that you do not get siuch high shear stress values on the inside edge of bends. Which in turn means that they fillup quite nicely as the meander progesses outwards.
<end>
Now seems that the line restricting froude # to 1, can lead to creating blockages in the channel - when there are very high potential shear stresses, the calced froude # is >1 and reducing velociy so the number is 1 leads to too low tau, which means material is not eroded and therefore builds up.
Also, quite possible that the too high froude # trip detailed above also over -promotes accumulation on the inside of bends. Am presently trying it without this line - and seems much better/smoother - though also early days.
A good illustration of going around in programming circles! |
|
|
|
|
| Version 6 coming very soon. Its nearly there now... |
|
|
|
|
| Remember to change the addition of Q in the route_lr etc.. routines to be /4 instead of /8 as now there are only 4 scans |
|
|
|
|
Been through a sucession of testing on different catchments/reaches/envrionments. ALso some changes in flow routing. Latest stable/good version 5.3bh.cs
Some words on the updates up to the version below.
Found that there was still some bias in the distribtion of Q due to the scanning routines. Tried random selection of up/down scanning - but whilst this led to good average distribtions of erosion and deposition, it led to very large fluctuations - and not an especially stable solution.
Now am scanning 8 times, but adding discharge (again) after 4, and not resetting the left_out, right_out etc.. arrays or the water depth. This seems to cancel out most of the sweeping/scanning directional bias. This is best checked using the lowmeander series of runs.
#5.3bh is a stable version at the moment,
Things to note, re-addition of calculating shear drag in Tau calcualtion (in calc_flow_dir()) seems to tidy things up nicely in the meandering/single thread versions - and create good single channel cells.
Getting very stable and smooth looking grainsize and Tau distributions using this version of Tau calculation (from V from Q).
This then led to a more in depth study of the lateral scheme - as it seems that once one part is sorted out, then weaknesses appear here. This in turn led to fairly close examination of how the inside and outside edges were calculated. This was an issue with the sub grid scale representation of how edges were calcualted, as the failure to integrate non-manhattan neighbours resulted in too many inside edge cells being added. Also over estimation of outside bends in certain cases. Tried along channel averaging using smaller cells, but that did not seem to make things any better. Now have introduced a couple of lines to prevent the addtion of too large inside bend counts. Seems to work well.
OK, so 5.3bh is working well with (generally) single thread channels and coping with meander migration well.
5.3bg- THen tried using 5.3bh on braided channel, and found that it tended to very strongly try and reduce the channel down to a single channel. This could be natural (check) =but seemed unlikely (using feshie2.xml). Tried reverting to using bed slope for shear stress etc.. but did not seem to make a huge difference.
Present thoughts are that this could be because water is allowed to be routed to 3-5 or more cells in front, whereas sediment can only go to three. Does this mean that sediment is not moved as far as the water is, which leads to the 'mining' of the centre of the channel, or is this because of other reasons. Certainly, the use of discharge to calcualte shear stress leads to very smooth beds - which is not necessarily something that might be expected in a braided river.
T |
|
|
|
|
Unfortuntely there has been a brief break in model development - as I managed to spill a pint of tea over my laptop - loosing about 3 weeks worth of development work. THe HDD is presently with a data recovery company.. and should get a version back soon.
Moral of the story is to back up data regularly, and that laptops dont like tea.. |
|
|
|
|
Right,
GOt my data back.
WOrking on 5.3bm - bn
Still working on the lateral functions
Had (proir to tea incident) found that lateral worked well in braided system (feshie) when just allowed lateral erosion to happen everywhere, but let the lateral gradient determine where the material dropped into the channel went.
In catchment mode, found htat had to add a check in erode_w so that when using bedslope to calculate Tau, the sediment was routed according to the bedslope, not the discharge gradients. Of course when its working on Vel Tau, then use discharge gradients.
Also, somewhere along the line, the bedrock limit seems to have been deleted! So it has been eroding below bedrock file on 5.3.
Tom |
|
|
|
|
Decided to release a beta version.
Should work fine - I would not recommend using the new lateral scheme at the moment - its quite untried. But if you fancy it, give me an email for some more advice,
Tom
Feedback, faults and comments all welcome. |
|
|
|
|
Things to check include:
Veg - whether it works in restricting surface erosion. New model that is in there needs full evaluation
Tracer - whether tracer functions are working correctly |
|
|
| Back to top |
