When is a node's nodeNr ever greater than the root's nodeNr?

[jacklo225]

Hi,
I have a quick question as given in the title, prompted by the private getNr() function in the RandomLocalClockModel class which contains a conditional checking for a nodeNr greater than the root's nodeNr. I also vaguely recall seeing similar checks previously in other locations but that may be a figment of my imagination.

Thanks!

[rbouckaert]

Good question -- by convention, the root should always have the largest number in the tree (i.e. 2n-1 for n taxa), so that meta-data associated with branches conveniently can be stored in an array of size 2n-2, and no special code required to deal with a root having a lower node number.

The getNr method is quite old code, so it may be a remnant of when this convention was not in place. Only during MCMC proposals when the root is replaced and not yet renumbered can the root number be lower than the current number. However, that is typically not a time when branch rates are requested from the clock model, so I suspect that bit of code is out of date.

[jwtlo]

In the case that there is an operator that proposes a topology move with a new root, how is the renumbering configured? I have a length 2n-2 array of parameters associated with non-root nodes and I'm not sure how to handle an internal node becoming the root (and the former root becoming a normal internal node).

[rbouckaert]

@jwtlo when proposing a new root node, the original root node is moved somewhere inside the tree, and the tree need to be told that there is a new root by calling Tree.setRoot(). At that point the root and internal node numbers are swapped.

If Tree.setRoot() is not called, the tree considers the old root still as root, and when traversing the tree (as in TreeLikelihood.traverse()) it will miss out on some of the taxa.