6.3 Merge Tree Transformation
6.3.2 Implementation
The implementation of the merge tree transformation is straightforward. Our implementation starts with the augmented merge tree of the first time step and two
lists of the grid vertices sorted descending by their values at the first and second time step. The first list will be re-ordered over time for correct determination of a node’s (changing) upper link. The second list is to determine potential transpositions of new arcs that occur after a transposition. The time of an arc collapse is inferred from the linear interpolation between the vertices’ values in the first and the second time step. To process all transpositions in the correct order we keep them in a priority queue. The algorithm ensures that if the nodes of an arc transpose, we insert them into the priority queue before the transposition takes place. In other words, we do not miss any arc collapses. Algorithm 3 provides a pseudo-code implementation of the transformation process. The code already contains commands necessary for feature tracking (cf. Chapter 6.4). Because feature tracking is independent from the transformation itself, these commands are commented out (using a double slash “//”).
Optimization
Although arc transpositions may change the structure of the merge tree, it turns out that many of them are topologically neutral and do not change the tree’s structure. This is especially true if the participating end-nodes of the collapsing arc are both regular nodes. Because it is necessary to process the fully augmented merge tree to not miss when regular nodes turn into critical nodes, for topologically neutral events between regular nodes, the traversal to validate u’s only child arc is a waste of time: the intermediate merge tree would be correct if we just switched nodes u and l.
For transposing regular nodes, which is by far the most frequent event, we can determine if a new maximum can appear without performing a traversal to validate u’s only child arc: a maximum can be born only if the vertices are neighbors in the grid. While this condition is necessary, but not sufficient, for the lower node to annihilate its upper link, its contrapositive—if the two vertices are not neighbors— ensures that a new maximum cannot be born. We insert the neighbor-condition into Algorithm 3 (Step 8) and quickly swap both regular nodes if they are not neighbored in the grid. The pseudo-code of this optimization is given in Algorithm 4.
6.3.3
Runtime Complexity
The number of arc collapses during the transformation depends on how many node pairs change their relative order in the sorted sequences of both time steps. That is, a transformation’s complexity depends on the structural variation of the function. In the worst case, if the vertices reverse their order, their number is bounded by O(n2),
Algorithm 3: Transformation of the merge tree of time step i into the
merge tree of time step i + 1. Optional parts are commented out.
Input : A merge tree M T for time step i
A list orderN ow of sorted grid vertices at time step i A list orderT hen of sorted grid vertices at time step i + 1 Output : A merge tree for time step i + 1 and tracking information 1 for each arc a = (u, l) in M T do
2 if u is behind l in orderT hen then
3 Push a on priorityQueue with priority swaptime ∈ [0, 1]
4 while priorityQueue is not empty do
5 Pop a = (u, l). (u is the upper node and l is the lower node closer to the root node) 6 // Handle outstanding superlevel tracking events, see Chapter 6.4.2
7 Put u behind l in orderN ow
8 // Optional optimization, see Algorithm 4 in Chapter 6.3.2 9 Remove a from M T
10 if l is not root node of M T then
11 Let a00= (l, p) be the arc incident to l towards the root 12 Remove a00 from priorityQueue
13 Remove a00 from M T
14 (Determine which of u’s children become l’s children) 15 Let N be the set of grid neighbors of l
16 for each neighbor n ∈ N do
17 if n is in front of l in orderN ow (i.e. in the upper link) then 18 if traversal from n towards M T ’s root node leads to u then 19 Let a0= (u, u0n) be the arc incident to u
20 Remove a0 from priorityQueue
21 Remove a0 from MT
22 Add arc (u0n, l) to M T
23 if u0n is behind l in orderT hen then
24 Push (u0n, l) on priorityQueue with priority swaptime
25 Stop traversal
26 else if traversal from n towards M T ’s root node leads to l then
27 Stop traversal
28 Add arc (l, u) to M T
29 if l was not root node of M T then
30 Let p be the parent node of l before the swap 31 Add arc(u, p) to M T
32 if u is behind p in orderT hen then
33 Push (u, p) on priorityQueue with priority swaptime
34 // Store tracking information for this swap event, see Chapter 6.4.1 35 // Update outstanding superlevel tracking events, see Chapter 6.4.2 36 // Handle outstanding superlevel tracking events, see Chapter 6.4.2
37 // Assemble tracking information for features of the complete function, see Chapter 6.4.1
for n tree nodes. Potential push-updates to the priority queue (Steps 24 and 33) take O(log a), for a arcs in the queue. For non-optimized events, the traversal to validate node l’s upper link depends on the number of tree nodes on the paths between l’s
Algorithm 4: Optimization if regular nodes pass each other (to be inserted
at Step 8 in Algorithm 3).
1 if isRegular(u) and isRegular(l) then
2 if u and l are not neighbors in the grid then
3 Let a0 = (u, u0) and a00= (l, p) be the arcs incident to a 4 Remove a0 from priorityQueue
5 Remove a00from priorityQueue 6 Swap node u and l
7 if u0 is behind l in orderT hen then
8 Push (u0, l) on priorityQueue with priority swaptime 9 if u is behind p in orderT hen then
10 Push (u, p) on priorityQueue with priority swaptime 11 Goto Step 4 of Algorithm 3
upper link nodes and l itself. Generally, this number is bounded by n, but depends on the function itself and on the grid’s granularity. In our experiments (cf. Chapter 7 and Chapter 8), however, we observed that the number of arc collapses is usually less than 5% of n2 and that the 90th percentile of the traversal lengths is around
10% of n; while no traversal was longer than 30% of n.