misaligned terminals in a dated phylogeny

[mmrochacupim-ship-it]

I have a phylogeny with dating, but the terminals are misaligned, and consequently the scale axis is meaningless.

I can only align them when I import the tree in Newick format, which doesn't save the node information.

Does anyone know how to solve this? I can't find anything about it in tutorials, and since the name "treeviewer" is very common in tree viewers, I can't find any solution on Google.

Thanks

[arklumpus]

Hi, thank you for using TreeViewer! Just to clarify, this is supposed to be an ultrametric tree, right? How was it produced?

But yes, it does indeed look a bit weird, would you please be able to send me the tree file (either here or via email at gb2177(at)bath.ac.uk)?

[mmrochacupim-ship-it]

Hi Arklumpus

Thanks for your response.

The tree is a Bayesian analysis of mitochondrial data, calibrated by fossil, generated by beast2/v2.6.2.
I need plot the height_95%_HPD bars (what I can do without much trouble), but I not understand what happened with the tips.
I saw in the examples that it could also be done by attaching a table with this information and leaving the tree in Newick format, but I couldn't figure out how to format the table to transpose the information.

[arklumpus]

Maybe there is some weird character in the tree file that is not parsed correctly... I would really need to see a tree file showing this problem to understand what is happening!

[arklumpus]

Thank you for sending me the tree file!

TLDR The solution is simple: in the tree file, just replace every occurrence of the text length= with length_mean=; in this way, the mean length will not overwrite the actual branch length computed by TreeAnnotator. You can do this in your favourite text editor (e.g., Notepad), or you can use the following command on Linux and macOS:

sed "s/length=/length_mean=/g" tree_file.tree > tree_file_fixed.tree

To get more in the details, the problem is that the tree produced by TreeAnnotator contains three different branch lengths (the following is an example for one node, the LCA of all the Nasutitermes_dryades_spn):

Assuming my understanding is correct:

• The green length is the mean of the branch length across all the posterior samples.
• The orange length_median is the median of the branch lengths across all the posterior samples.
• The blue branch length is computed by looking at node ages (heights) - i.e. the length of a branch is the difference between the height of the end node and the height of its parent node.

The problems here are: 1) the green and orange lengths do not produce ultrametric trees; 2) the green length overwrites the blue length. Basically, when TreeViewer opens the tree file, it proceeds like this:

• It finds the unlabelled blue length attribute (e.g., :15.125766), and it correctly assumes that it represents the branch length, which it stores in the Length attribute.
• It then finds the explicitly labelled length attribute (e.g., length=15.124460371706174), and since attribute names are case-insensitive, it overwrites the previous value.

Therefore, the original branch length that would produce an ultrametric tree is lost. By replacing the name of the mean length attribute as I mentioned above, you avoid overwriting the actual Length attribute.

[mmrochacupim-ship-it]

Thank you very much!

Any idea why this happened? What is the setup difference between the output of the programs? I know I used an older version of BEAST2.
I found it curious that it plotted other elements (like node bar intervals) in the correct positions.

[arklumpus]

It seems that the TreeAnnotator in both the original BEAST and BEAST2 produce this kind of trees (that contain an annotated length attribute, as well as an implicit branch length).

The crux of the problem is that the original Newick tree specification (upon which the NEXUS tree format is based) only allowed specifying a label and a length for a node, without any provision for additional attributes. Therefore, each program that needs to store additional attributes (e.g., support values, heights/ages, rates, colour, etc.) has had to "hack" the format to do this, and everyone does it in a different way (e.g., using slashes as separators, including attributes within square brackets, etc). This is not a problem if you only use software from the same suite, but it can cause a lot of intercompatibility nightmares.

TreeViewer uses a "Newick-with-attributes" format that aims to be compatible with most other phylogenetic tools; this format allows specifying any kind of attribute as a <name>=<value> pair, but for "special" attributes (Name, Length and Support), the attribute name can be omitted and the format description provides an algorithm to "guess" to which attribute each value corresponds.

For example, this tree: (A:1,B:2)0.5:3 is equivalent to the more explicit:

(()Name=A:Length=1,()Name=B:Length=2)Support=0.5:Length=3

But TreeAnnotator produces trees that contain both an implicit branch length (i.e., a number after a :), as well as an explicitly named length attribute with a different value. Since the same attribute is specified twice, one of the two values must be lost... And in this case it is the implicit value that is overwritten. My workaround above renames the explicit length attribute into something else, so that the naming conflict is avoided by having two different attribute names.

The node bars are not affected by the problem , because they use other attributes (e.g., height_95%_HPD) that are only specified once for each node.

[mmrochacupim-ship-it]

Thank you very much!

It was very helpful.