| Message/Author |
|
|
|
|
Hello,
The main changes from the previous version.
1. 6.2c now has variable checking function - so it sees whether sensible variables havebeen entered - Then when you click load data a message box comes up that may give you a series of warnings about the values/parameters you have entered. The model will still run with these values - it does not change them for you or stop them from running - but it does warn and suggest alternatives/better values
2. Tau (by this I mean the shear stress) calculated by velocity. The previuos version led to scour holes - (sometimes ravines) being carved out int he bed of the channel - and I tried - and thought for quite a while how to solve this. This is done in two stages. Firstly, Tau is calculated in every direction where there is a positive discharge (where there is flow) from the velocity. THEN, it checks to see whether or not it is upslope - and if so then it reduces the Tau according to the depth slope product in the opposite direction.
The Tau's in all directions are then summed (the force acting on the cell in question) and then material is eroded from that cell and distributed according to the balance of the Tau's in each direction etc...
3. The Drag coefficient term in the shear stress calculation (Ci in the code) was held as a constant - to stop very high values for very small depths. This has been relaxed - to allow erosion in headwaters of tribs in catchment mode. This does lead to issues in reach mode of erosion of the edge of the banks when there are overbank flows - maybe this is something that needs to be looked at in more detail
4. Lateral erosion. This has been simplified to two schemes. The first will erode a proportion from the bank of what is being eroded from the stream bed in the adjacent cell. here the lateral constant controls the amount. This seems to work well. The second scheme is more like previous version where it relates it to near bank shear stress and radius of curvature. Its hard to know which one works best/is better. Methods similar to the first one seem to be favoured in other studies/morphological models that include lateral erosion.
Tom
3. Lateral erosion |
|
|
|
|
6.2e, f, g and h (notes to self)
6.2e good - f and g after lengthy spells with the profiler finding out what is causing slow points.
Some minor changes in f and g (notably in g erode3 is called from erodew and erodebedslope and dist[] is zero'd within erodew and erodebedslope instead of in erode before it is called saves anothr 5%).
Found error in erode3 - where variable total was not being zero'd in the right place. This total tots up the amount of material that wants to be moved from a cell and then uses the total to reduce the amount that can be moved if there is not enoguh available. If it is not being zero'd then it means that there will be less erosion (more supply limited). It will be interesting to see if this makes a major difference or not - in theorey it should make the grainsize work better- and is (unfortunately) a bug that has probably been there for 8 years or so...
update - some intitial tests show this can make quite a difference - especially in catchment mode. Basically it means there will be more sediment supply... this may mot necessarily make a huge difference - but will mean spin up time takes longer..
Parallel stuff.
h has some messy changes to do with the parallel section tracking down where there is unsafe code. Also merged erodew and erode3 so that the dist[] array can be replaced with a local dist2[] array to try and prevent any data leakages. This source is messy - and contains several lock(this) statements to try and nail down which parts of the code are causing problems. Still not solved - though managed to get it to work with some sectionslocked out - though not sure how much difference that makes |
|
|
|
|
The actual line in the code is here: (total=0)
if (index[x, y] == -9999) addGS(x, y);
temp_centre = index[x, y];
for (fract = 1; fract <= 9; fract++)
{
total = 0;
for (n = 1; n <= 8; n++)
{
total += dist[x, y, n, fract];
}
/******* lines like the next one, are assential to ensure that it adds new eroded sqaures to the list. **/
if (grain_tot(temp_centre, fract) > 0.0001)
{
} |
|
|
|
|
OK - to make this clear, from versions 6.0a to 6.2e you NEED to change the lines in the function erode3() from:
void erode3(int x,int y)
{
int n,temp_centre, fract;
double total=0;
double total2=0;
if(index[x,y]==-9999)addGS(x,y);
temp_centre=index[x,y];
for (fract = 1; fract <= 9; fract++)
{
for (n = 1; n <= 8; n++)
{
total += dist[x, y, n, fract];
}
TO THE BELOW:
private void erode3(int x,int y)
{
int n, temp_centre, fract;
double total = 0;
if (index[x, y] == -9999) addGS(x, y);
temp_centre = index[x, y];
for (fract = 1; fract <= 9; fract++)
{
total = 0;
for (n = 1; n <= 8; n++)
{
total += dist[x, y, n, fract];
}
Which is simply adding one line total=0;... |
|
|
| Back to top |
|
