<p>I found the answer on <a href="https://www.researchgate.net/post/BEAST-Real-long-branches-causing-negative-branch-lengths" rel="nofollow noreferrer">ResearchGate</a> from Santiago Sanchez-Ramirez &amp; let me quote it here:</p>
<blockquote>
<p>Try using the option <code>-heights ca</code> when you run TreeAnnotator. This stands for &quot;common ancestor trees&quot; 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.
<a href="http://beast.community/faq.html" rel="nofollow noreferrer">Here</a> is the explanation for negative branches:
&quot;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.&quot;
In this paper you will find more information about the <code>ca</code> option: <a href="https://www.researchgate.net/publication/257460818_Looking_for_trees_in_the_forest_Summary_tree_from_posterior_samples" rel="nofollow noreferrer">Looking for trees in the forest: Summary tree from posterior samples</a></p>
</blockquote>

CC BY-SA 4.0
2022-03-28T10:57:48.880Z
2022-03-28T10:57:48.880Z
Vovin
<p>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.</p>
<p>One issue raised however is something called 'burnin'.</p>
<p><strong>Burnin is foundational to MCMC</strong>.</p>
<p>In the comments I stated the burnin is too low. The burnin used ...</p>
<pre><code>~/beast/bin/treeannotator -heights median -burnin 20 ...
</code></pre>
<p>The OP believes the burnin represents a percentage, i.e. 20%.</p>
<p>Citing the documentation on TreeAnnotator at <a href="https://beast.community/treeannotator" rel="nofollow noreferrer">https://beast.community/treeannotator</a></p>
<blockquote>
<p>BurnIn (as trees)
In this case you just specify the actual number of
trees you wish to discard rather than the number of states.</p>
</blockquote>
<p>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.</p>
<p>It is easy to assess empirically e.g. comparing <code>wc infile</code> and <code>wc outfile</code>, where infile and outfield are MCMC treefiles.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>Perhaps you can now see my point?  Not the specific technical matter above, but the issue concerning complexity and time commitment.</p>
<hr />
<p>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.</p>
<p>The TreeAnnotator section of the Beast2 documentation is here <a href="https://www.beast2.org/treeannotator/" rel="nofollow noreferrer">https://www.beast2.org/treeannotator/</a></p>
<blockquote>
<p>TREEANNOTATOR ....</p>
</blockquote>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>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'.</p>
<p><strong>Note</strong>  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.</p>
<p><em>Its definitely time to move on</em></p>
<p>OP upvoted, good luck with the project and all the best.</p>

CC BY-SA 4.0
2022-03-25T13:17:01.930Z
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.`.
Vovin
CC BY-SA 4.0
2022-03-25T13:18:24.587Z
So the question is about possible common reasons of such phenomenon.
Vovin
CC BY-SA 4.0
2022-03-25T17:21:39.853Z
Dear @Vovin I have addressed the first comment you raised above as an append to previous answer below the separator.
M__
CC BY-SA 4.0
2022-03-25T17:28:53.180Z
I have addressed the second point you raised in the section called **Note**
M__
CC BY-SA 4.0
2022-03-26T16:02:28.460Z
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](https://github.com/CompEvol/beast2/blob/master/src/beast/app/treeannotator/TreeAnnotator.java) where this variable is called as `burninPercentage` & used in the appropriate way.
Vovin
CC BY-SA 4.0
2022-03-26T16:07:36.300Z
Moreover, for instance, `treeannotator -heights median -burnin 101 -limit 1 example.trees example.tree` gives `beast.app.util.Arguments$ArgumentException: Argument, -burnin has a bad integer value: 101`. But it works with 99. The example from exeption message: `Example: treeannotator -burnin 10 -heights mean test.trees out.txt`. It is obvious that this is not a number because it would be too small. I was myself confused in the past by the blog article that you cited but it works as percentage.
Vovin
CC BY-SA 4.0
2022-03-26T16:07:46.957Z
Time to move on
M__
CC BY-SA 4.0
2022-03-25T11:50:49.330Z
2022-03-25T20:57:18.157Z
2022-03-25T20:57:18.157Z
M__
<p>BEAST2 is currently being used for tree reconstruction prior phylogeographic analysis. The sample size and loci are described below.</p>
<p>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 <strong>FigTree</strong>.</p>
<p><a href="https://i.sstatic.net/Ur9MA.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Ur9MA.png" alt="A part of one of my trees" /></a></p>
<p><strong>Question</strong> What could be the reason of this and how to wrestle with this phenomenon?</p>
<p>I am analysing about 1500 taxa of HAV (subtype: IA, region: VP1) under the next parameters:</p>
<ul>
<li>GTR+Г,</li>
<li>Strict Clock,</li>
<li>Coalescent constant population.</li>
</ul>
<p>The tree was generated by <strong>TreeAnnotator</strong> through</p>
<pre><code>~/beast/bin/treeannotator -heights median -burnin 20 -limit 0.5 VP1_test_bt_ExpPop.trees VP1_test_bt_ExpPop.tree
</code></pre>

CC BY-SA 4.0
2022-03-24T17:01:37.810Z
Is this an issue of the tree that was generated or an issue of the algorithm that makes the layout for plotting the tree?
Pallie
CC BY-SA 4.0
2022-03-24T17:28:52.193Z
Not either/or @pallie. The tree drawing program should be excluded.
M__
CC BY-SA 4.0
2022-03-24T17:35:36.740Z
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_
Pallie
CC BY-SA 4.0
2022-03-25T08:45:38.920Z
@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=`
Vovin
CC BY-SA 4.0
2022-03-25T08:46:42.400Z
@M__ 20 is not a number. This is percentage.
Vovin
<phylogenetics><phylogeny><beast>
What can be the reason of getting negative branches lengths after BEAST analysis?
# What can be the reason of getting negative branches lengths after BEAST analysis?

(Asked by: username_0 on 2022-03-24)

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.

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

**Tags:** phylogenetics, phylogeny, beast
> **Comments:**
> **username_1**: Is this an issue of the tree that was generated or an issue of the algorithm that makes the layout for plotting the tree?  
> **username_2**: Not either/or @pallie. The tree drawing program should be excluded.  
> **username_1**: 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_  
> **username_0**: @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=`  
> **username_0**: @M__ 20 is not a number. This is percentage.  

---

## 2 answers

### Answer by username_0 on 2022-03-28. Score: 2 | Accepted answer

I found the answer on [ResearchGate](https://www.researchgate.net/post/BEAST-Real-long-branches-causing-negative-branch-lengths) 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](http://beast.community/faq.html) 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](https://www.researchgate.net/publication/257460818_Looking_for_trees_in_the_forest_Summary_tree_from_posterior_samples)


---

### Answer by username_2 on 2022-03-25. Score: 0

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.

> **Comments:**
> **username_0**: 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.`.  
> **username_0**: So the question is about possible common reasons of such phenomenon.  
> **username_2**: Dear @Vovin I have addressed the first comment you raised above as an append to previous answer below the separator.  
> **username_2**: I have addressed the second point you raised in the section called **Note**  
> **username_0**: 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](https://github.com/CompEvol/beast2/blob/master/src/beast/app/treeannotator/TreeAnnotator.java) where this variable is called as `burninPercentage` & used in the appropriate way.  
> **username_0**: Moreover, for instance, `treeannotator -heights median -burnin 101 -limit 1 example.trees example.tree` gives `beast.app.util.Arguments$ArgumentException: Argument, -burnin has a bad integer value: 101`. But it works with 99. The example from exeption message: `Example: treeannotator -burnin 10 -heights mean test.trees out.txt`. It is obvious that this is not a number because it would be too small. I was myself confused in the past by the blog article that you cited but it works as percentage.  
> **username_2**: Time to move on  

---

