Yet another PR to try and resolve issues with avulsion routing and unmarking.
description
There were a few really difficult cases I was brushing up against, that I just couldn't wrap my head around how to tackle. For example, this case below, which contains a loop on a loop at the end of a single-distributary network. The trouble here was that in trying to abandon cells 4041 and 4042, the algorithm would become stuck, because each would have flow coming from another location and thus stop further unmarking. So I needed to implement a way to force the unmarking algorithm, to walk these pathways under some circumstances: the abandonAll flag, which is now an argument to unmarkChannelToNode.
There were other difficult scenarios I tried to work through, but I'm just struggling to think about how to unmark looped channels in a safe and effective way. If we decide a refactor is in order, a different unmarking approach to mine could be to just try and remove the one link that forms the loop and move on. It may end up being called a bunch of times in a row (if the loop reforms on a subsequent avulsion), but eventually will be abandoned by a larger-order avulsion...
I've also gone against what we discussed in #27 topic 2, and prevented avulsions from going anywhere uphill. Truthfully, this just simplifies the heck out the scenarios that form loops (routing avulsions into small-number-of-cells sinks) and instead just prevents that avulsion from happening. I think this is conceptually fair too, but we could undo this change if you like (just the third commit 9e4551d3505305b94ad88036acc335632b1bd8fe). Anyway, an avulsion eventually happens elsewhere that causes this channel to be abandoned.
result
after 8.0 years of simulation. Then, an out-of-range error occurred in checkNeighborsChannelsCrossover (oops, forgot to pad the array first).
summary
Yet another PR to try and resolve issues with avulsion routing and unmarking.
description
There were a few really difficult cases I was brushing up against, that I just couldn't wrap my head around how to tackle. For example, this case below, which contains a loop on a loop at the end of a single-distributary network. The trouble here was that in trying to abandon cells 4041 and 4042, the algorithm would become stuck, because each would have flow coming from another location and thus stop further unmarking. So I needed to implement a way to force the unmarking algorithm, to walk these pathways under some circumstances: the
abandonAllflag, which is now an argument tounmarkChannelToNode.There were other difficult scenarios I tried to work through, but I'm just struggling to think about how to unmark looped channels in a safe and effective way. If we decide a refactor is in order, a different unmarking approach to mine could be to just try and remove the one link that forms the loop and move on. It may end up being called a bunch of times in a row (if the loop reforms on a subsequent avulsion), but eventually will be abandoned by a larger-order avulsion...
I've also gone against what we discussed in #27 topic 2, and prevented avulsions from going anywhere uphill. Truthfully, this just simplifies the heck out the scenarios that form loops (routing avulsions into small-number-of-cells sinks) and instead just prevents that avulsion from happening. I think this is conceptually fair too, but we could undo this change if you like (just the third commit 9e4551d3505305b94ad88036acc335632b1bd8fe). Anyway, an avulsion eventually happens elsewhere that causes this channel to be abandoned.
result
checkNeighborsChannelsCrossover(oops, forgot to pad the array first).