I don't have a whole lot of new stuff to show this week, as I have mostly been overhauling the calculation code. It was originally written to work with Child, and it has evolved somewhat haphazardly during the past 4 months to accommodate all the changes that have been made to the meandering process and the overall simulation. So, in preparation for performing the multiple runs in September, I have tried to bring it up-to-date and make it more efficient. I would also prefer, if possible, to avoid having to write C code for performing any part of the calculations, and to keep everything in Python.
The result of this work has been to effectively speed up the calculations anywhere from 3x to 5x, depending on how you look at it. I was able to speed up the meandering steps by about 3x, so that each step now takes well less than one second for a 1000 point river. Unfortunately, however, the bulk of the simulation time is taken by the boundary checks and cutoff checks and removals, so that while it is possible to perform a 1000 step simulation without boundary or cutoff checks in about 15 minutes, the same simulation with boundary and cutoff checks (every 10 steps) takes almost 2 hours. Actually this is good news, as the first constrained full-river tests I did earlier this month took about 10 hrs each. My goal is to get each run down to under 1 hr. I may be able to do this in pure Python, or I might need to perform either the boundary or cutoff checks using C. I'll figure that out next month.
I have also tried to create some simulations with deliberately bigger 'loops'. As I said a few weeks ago, getting big loops using my meandering routines is nothing special; mostly it involves picking the proper distances used for curvature averaging. One downside to bigger loops seems to be that the river may then 'hug' the valley wall for protracted periods and distances, as there is little or no downstream variation in curvature to make it do anything else (see images below). Getting big loops with Johannesson-Parker, however, is still an unkown, and a question of picking the proper combination of other physical parameters. I'll be looking into that next week (including using much larger flows). Nevertheless, I could probably use my curvature averaging code with JP, and bigger loops would 'magically' appear for any set of physical parameters you wanted to use (provided they didn't crash the JP calculations).
In the screenshots shown below, the meandering method was 'simple curvature'. That is, the cross-stream migration is linearly proportional to the signed curvature and nothing else. The routine doesn't depend on flow or depth, and only depends on width to the extent that the curvature averaging distances are multiples of local width. I did this to demonstrate that the essential features of meandering have little to do with the physical parameters, or with complicated differential or integral equations. Nevertheless, I'll return to the 'speed based' methods (including JP) next week.
In the simulations below, I have also 'clipped' the river width to a maximum value of 400 m and below, as I think that is more representative of the actual meandering width, especially in segments where I have disregarded islands, shallows, and multiple channels (e.g. at 'Goat Island'). You and I seem to agree that the water surface and bank width are a deceptive kind of 'event horizon' which hide the fast-flowing, narrow, submerged conduits which are actually responsible for sediment exchange and river migration. A consequence of this hypothesis is that there may be a planform beneath the visible planform, and that the surface width of the river may be just the 'hull' or 'envelope' of the active submerged planform. I would still like to investigate this possibility later this year, if time permits.
In the following simulations, the river was re-interpolated to 100 m between each step:
test # = 3 method = simple curvature migration rate = 2500 exponent = 1.0 lag distance = 0.5 widths sum distance = 1.0 widths width = limited to 400 m boundary and cutoff checks = no
test # = 7 method = simple curvature migration rate = 5000 exponent = 1.0 lag distance = 0.5 widths sum distance = 2.0 widths width = limited to 400 m boundary and cutoff checks = no
test # = 13 method = simple curvature migration rate = 20000 exponent = 1.0 lag distance = 0.5 widths sum distance = 4.0 widths width = limited to 400 m boundary and cutoff checks = no
test # = 14 method = simple curvature migration rate = 20000 exponent = 1.0 lag distance = 0.5 widths sum distance = 6.0 widths width = limited to 400 m boundary and cutoff checks = no
test # = 18 method = simple curvature migration rate = 7500 exponent = 1.0 lag distance = 0.5 widths sum distance = 2.0 widths width = limited to 400 m boundary and cutoff checks = yes
test # = 19 method = simple curvature migration rate = 30000 exponent = 1.0 lag distance = 0.5 widths sum distance = 4.0 widths width = limited to 400 m boundary and cutoff checks = yes
In the following simulations, the river was decimated by 4x and then re-interpolated to 100 m between each step:
test # = 15 method = simple curvature migration rate = 20000 exponent = 1.0 lag distance = 0.5 widths sum distance = 4.0 widths width = limited to 400 m boundary and cutoff checks = yes
test # = 22 method = simple curvature migration rate = 100000 exponent = 1.0 lag distance = 0.5 widths sum distance = 4.0 widths width = limited to 400 m boundary and cutoff checks = yes
test # = 16 method = simple curvature migration rate = 50000 exponent = 1.0 lag distance = 0.5 widths sum distance = 8.0 widths width = limited to 400 m boundary and cutoff checks = yes
test # = 17 method = simple curvature migration rate = 50000 exponent = 1.0 lag distance = 0.5 widths sum distance = 8.0 widths width = limited to 400 m boundary and cutoff checks = yes
