More Child Tests

During the past few days, I've done more work on branching flows. I acknowledge that this probably isn't required for the current project, but I maintain that it was a good way for me to become familiar with the Child code, as I am now comfortable making modifications and recompiling it. I will need to make substantial modifications next month for the new meandering code, so this was a good way to start without breaking anything right away :-).

Two new modifications I've made are:

1. The branching algorithm now works its way upstream rather than downstream from each node. This has the effect of evaluating the flow (drainage area) at each node only once, and recursively evaluating upstream nodes on demand to determine their total flow contribution all at once, rather than repeatedly adding the partial flow contributions from every possible downtream path to every node over and over again. See below for an example/explanation of why this is important. The upshot is that the calculation now takes virtually no time rather than virtually infinite time.
   
   
2. Lakes are now supported (which was trickier than it sounds), so that the entire flow contribution of a lake is added to its perimeter outlet all at once, and infinite loops (and loop order evaluation differences) are avoided by not traversing downward edges into lakes.

Here is an example of a single inlet flowing onto a smooth inclined plane. The plots show (from upper left to lower right) all flows of magnitudes ≥ 1e6 (just the inlet), 1e5, 1e4, 1e3, 1e2, and finally 1e-6:

If the flow was evaluated downward, a contribution from every possible upstream path would have to be added to all downstream nodes. Since the mesh is hexagonal and has 3 downward paths from every node, that would require evaluating on the order of 3^{nodes-in-length-of-mesh} possible pathways (although this is also constrained by the width of the mesh) for every node. For a mesh with 25x25 active nodes, this is roughly 25 * 3²⁵ = 2e13 paths (actually more). At a calculation speed of 1e6 paths/second, that would require about 2e7 seconds, or just over 231 days. Evaluating the flow upward (by recursively evaluating all upstream nodes as necessary only once), the calculation can be performed in order N time (≤ 1 second).

Here is the current code (from tStreamNet.cpp), if you want to see the grisly details. Most of the action takes place in RouteFlowArea(). Lakes are handled in DrainLakes(). It's not well commented yet, and there are some spaces vs. tabs indentation issues, but you should be able to get an idea of what's going on. At present branching flows support the drainage areas and the lakes, but not the erosion or sediment transport. This is all the work I'm going to do on this now, as I need to go on to the meandering code in March. The option to use branching flows is now set in the input file, and so can remain 'off'.

Here are two examples of an inlet on a bumpy inclined plane. At left are the single-flow simulations, at right are the multi-flow simulations (for all flows ≥1e-6). I've also moved the inlet display to its proper elevation:

Here's an example of a single and multi-flow on a smooth inclined plane with sinusoidal variation in elevation. Note that some of the lakes appear to be disconnected because I'm not plotting the entire lake or the flow from the bottom of each lake to its outlet (up the far bank):

Here's the same thing with some additional (100x) rain everywhere (single=left, multi=right):

I just noticed that I'm not always getting the single-flow output in my multi-flow case (since the former is based on flow edges and the latter strictly on geometry). So, I modified the program to add the two together. Here's both (with rain) at a flow threshold of 1e-6 (left) and 1e-7 (right):

Some lakes still appear disconnected, but that's an artifact of the plotting threshold. Actually, there is 'flow' everywhere, as can be seen when the threshold is set to zero:

Adding the single and multi-flow cases together improves the display for the 'very rough' inclined plane (inlet only) as well:

Here with more rain added (at thresholds of 1e-6 and 1e-7):

Note that as more rain is added, the distinction between the flow from the inlet and from other terrain runoff is blurred. This is because some rain is required to produce flow from the inlet, and there is no logic in the program to track flow from the inlet as opposed to other runoff. Ideally, these two would be calculated and output separately so that they could be distinguished in a plot.

I think I've successfully performed my tasks for this month, which were:

1. To get the Child code to compile and run under OS X.
2. To run some tests and compare them to previous results.
3. To convince ourselves that Child appears to be working nominally.
4. To write some simple ancillary mesh and graphics programs.
5. To perform some new tests.
6. To become familiar with the code.
7. To be able to make modifications to the code in order to enhance the program.

Next month I will:

1. Become more familiar with the stream meandering code.
2. Begin to write the Johannesson and Parker (1989) modifications to the meandering code.
3. Enhance the graphics and other ancillary code to be more useful, especially in the context of specifying and tracking stream geometries.