4
$\begingroup$

BEAST2 is currently being used for tree reconstruction prior phylogeographic analysis. The sample size and loci are described below.

I thought that BEAST/BEAST2 does not allow negative lengths of branches on prior distribution level so I was surprised when I have looked at my consensus tree using FigTree.

A part of one of my trees

Question What could be the reason of this and how to wrestle with this phenomenon?

I am analysing about 1500 taxa of HAV (subtype: IA, region: VP1) under the next parameters:

  • GTR+Г,
  • Strict Clock,
  • Coalescent constant population.

The tree was generated by TreeAnnotator through

~/beast/bin/treeannotator -heights median -burnin 20 -limit 0.5 VP1_test_bt_ExpPop.trees VP1_test_bt_ExpPop.tree
Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ Is this an issue of the tree that was generated or an issue of the algorithm that makes the layout for plotting the tree? $\endgroup$
    – Pallie
    Mar 24, 2022 at 17:01
  • $\begingroup$ Not either/or @pallie. The tree drawing program should be excluded. $\endgroup$
    – M__ ♦
    Mar 24, 2022 at 17:28
  • $\begingroup$ What I mean is, does the topology of the tree as saved on disk match the topology of the tree drawn in the graph? @M_ $\endgroup$
    – Pallie
    Mar 24, 2022 at 17:35
  • $\begingroup$ @Pallie It is the problem of the tree. For instance, =0.008838086259721895]:0.6701304093024589)[&posterior=0.005774216356351638]:-0.3146123701838377,(((26[&height=7.0,height_95%_HPD= $\endgroup$
    – Vovin
    Mar 25, 2022 at 8:45
  • $\begingroup$ @M__ 20 is not a number. This is percentage. $\endgroup$
    – Vovin
    Mar 25, 2022 at 8:46

2 Answers 2

Reset to default
2
$\begingroup$

I found the answer on ResearchGate from Santiago Sanchez-Ramirez & let me quote it here:

Try using the option -heights ca when you run TreeAnnotator. This stands for "common ancestor trees" and aims at summarizing clade ages across all posterior trees and not only the values for subset of trees that have that clade. If that subset of trees is low in frequency the average node height might end up being older than the direct ancestor. Here is the explanation for negative branches: "MCC trees produced by TreeAnnotator can have a descendent node that is older than its direct ancestor (a negative branch length). This may seem like an error but is actually the correct behaviour. The MCC tree is, by default, generated with average node heights across all trees in the sample which contain that clade. The negative branch lengths result when a clade is at low frequency and tends not to occur in those trees that have the MCC tree's ancestral clade (or vice versa). This means the average heights are for the adjacent nodes are derived from different sets of trees and may not have any direct ancestor-descendent relationship." In this paper you will find more information about the ca option: Looking for trees in the forest: Summary tree from posterior samples

Improve this answer
$\endgroup$
0
$\begingroup$

I am avoiding directly answering the question because in summary, I feel, this given issue is akin to project supervision and is simply too much time.

One issue raised however is something called 'burnin'.

Burnin is foundational to MCMC.

In the comments I stated the burnin is too low. The burnin used ...

~/beast/bin/treeannotator -heights median -burnin 20 ...

The OP believes the burnin represents a percentage, i.e. 20%.

Citing the documentation on TreeAnnotator at https://beast.community/treeannotator

BurnIn (as trees) In this case you just specify the actual number of trees you wish to discard rather than the number of states.

In this given case, considering this is 1500 taxa, I would estimate the actual burnin used in comparison to an initial assessment of completion time (technically called 'convergence') to be 0.4% maximum, i.e. well over 0.5 log smaller than the burnin believed to be used.

It is easy to assess empirically e.g. comparing wc infile and wc outfile, where infile and outfield are MCMC treefiles.

A standard burnin is 10% of the total MCMC. The threshold would be independently assessed and if inadequate a higher burnin would be used, of which 20% is reasonable.

To explain the documentation, in an MCMC only a sample of the trees are written to disk (often 1 in 1000, but it can be anything) and the burnin is 10% of the total (unsampled).

Thus factoring the sampling is important in calculating the precise burnin in any MCMC output analysis. Otherwise the burnin that was intended, isn't the burnin used in practice.

Perhaps you can now see my point? Not the specific technical matter above, but the issue concerning complexity and time commitment.

To address the matter concerning Beast1 vs Beast2 raised as a comment below, i.e. the proposal the original MCMC was performed in Beast2 and Beast2 is exempt. The issue under discussion is TreeAnnotator.

The TreeAnnotator section of the Beast2 documentation is here https://www.beast2.org/treeannotator/

TREEANNOTATOR ....

BurnIn This option allows you to select the amount of burn-in, i.e., the number of samples that will be discarded at the start of the run, so that you are only analysing the part of the trace that is in equilibrium.

Again the Beast2 documentation is clear, 'the number of samples', not the percentage or proportion. Furthermore note it states 'samples', not 'states', i.e. the number of trees resulting from the sample frequency that was assigned.

A burnin can be performed prior to TreeAnnotator analysis and that is good practice, albeit not essential. This might be where the report output the OP cites was obtained. Furthermore, if this was done here upstream, then no burnin is required for TreeAnnotator. Moreover if a correct upstream burnin was performed, burnin should either be; avoided for TreeAnnotator, or else the total combined burnin calculated and correctly reported. The final output ain't just a tree, there's a lot of important analysis/ 'meta data'.

Note I agree with the OP's second comment below this answer using information from the comment below the question: a value of -0.31 can't be ignored, i.e. its a notable value for any branch length and very large in the given context.

Its definitely time to move on

OP upvoted, good luck with the project and all the best.

Improve this answer
$\endgroup$
7
  • $\begingroup$ This is correct for BEAST 1, if I memorise this well. In BEAST 2 the parameter -burnin or -b is percentage. Because it is specified in the -help message & you cannot specify any number above 100 without an exception. Moreover, there are numbers of treated & total trees in stdout of treeannotator. For example, from my another analysis with 10% burning: Processing 18669 trees from file after ignoring first 10% = 2074 trees.. $\endgroup$
    – Vovin
    Mar 25, 2022 at 13:17
  • $\begingroup$ So the question is about possible common reasons of such phenomenon. $\endgroup$
    – Vovin
    Mar 25, 2022 at 13:18
  • $\begingroup$ Dear @Vovin I have addressed the first comment you raised above as an append to previous answer below the separator. $\endgroup$
    – M__ ♦
    Mar 25, 2022 at 17:21
  • $\begingroup$ I have addressed the second point you raised in the section called Note $\endgroup$
    – M__ ♦
    Mar 25, 2022 at 17:28
  • $\begingroup$ This is not productive for seeking the solution of the question but I think that I should point this out so others do not get confused by your answer. This is certainly percentage & the fact is based on the next evidence: the help message of the programme where it is named as percentage, the log message where the number is equal to my burnin times the total trees number, & the source code where this variable is called as burninPercentage & used in the appropriate way. $\endgroup$
    – Vovin
    Mar 26, 2022 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.