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.
=0.008838086259721895]:0.6701304093024589)[&posterior=0.005774216356351638]:-0.3146123701838377,(((26[&height=7.0,height_95%_HPD=
$\endgroup$