config update: planning tree

<a tree of update history>
1 why?
- at each new update, unexpected results may come out, they may differ from the previous parent type
- this can be recursive; at each node, we can only deal with one type of error; assume after we deal with type 2, 3, 4 at itera 4, which is a result of type 2 in iter 3, we wanna go back to type 4 in iter 3.
- so, we need a tree to store the state of: parent list of error type, their state of completion (yes/no),

2 use what for a tree
- why not structure?
- because every time u run an iteration, i creates half-complete nodes, and then in next iteration, u need to go back, structure doesn't allow you to go back without a pointer.
- a matrix table
- [v_node(1);
...
v_node(i) ]
- node: [i_branch,
i_parent,
vi_child,
i_iter,
i_type,
b_done],
i_node_active
- children (x3) stay together linearly. no explicit Parent node, they are from prev 3-unit group. So 3x siblings in a row

3. when to add node?
- when updating config and generates new error group stage files, they have to be properly named to reflect the tree structure: branch, iter/tree-level, type/leaf, to avoid being overwritten by other updates or overwriting existing ones.
- depth first: add occupiors for siblings all at once, then add childrens before implementing siblings

4. how to update nodes
- when creating:
- direct: i_type, b_done
- derive: i_parent, i_iter, i_branch, (invoke parent), new subgrid filename.
- should be known when running this iteration
- unknown: vi_child (?)
- when updating:
- parent node invoked by the newly added child nodes to the tree
- parent add vi_child
[i_branch,
i_parent,
vi_child,
i_iter,
i_type,
b_done],
5. how to traverse, save, and load tree
6. how to name the output files