RAxML bipartion node support

[Michael Jowers]

Dear all,

I find that the RAxML bipartition file can sometimes show no support for some branches that are often highly supported in Bayesian analyses (e.g., 1.00 Posterior Probability)....However, when I run the RaxML bootstrap file to build a 50% Majority Rule consensus tree in PAUP the node support is often highly congruent to the Bayesian Analyses, almost identical in most cases.

I normally use the second option (50% Majority Rule Consensus tree) as I find higher congruence with MrBayes....but can anyone explain me why the node supports are so different between the bipartition file and MrBayes, and what is best to use (ie.bipartition file or a more traditional 50% Majority Rule Consensus tree).

Thanks in advanced,

Michael

[Michael Jowers]

Looking more into it, it is always the node (from the bipartition file) after the outgroup that is not supported in the tree (in the consensus tree it is 100). I presume that this is just as a consequence of the rooting or how RAxML works the bipartitions...

--
You received this message because you are subscribed to a topic in the Google Groups "raxml" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/raxml/uzlNe8rtZE8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to raxml+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Grimm]

Morning Michael,

there is no difference in how RAxML (or other ML programmes) and MrBayes (or other Bayesian programmes) compute support values. The values are simply counted from the samples and reflect the frequencies of a given taxon bipartition (= a branch in your tree) in the tree sample, i.e. the bootstrap sample in case of ML-bootstrapping and non-burned sampled topologies in case of Bayesian inference.

Usually, PP and ML-BS are congruent, although PP can tend to overestimate support and ML-BS can be underestimating (hence the current arbitrary thresholds for good support, BS > 70, PP > 0.95).
A clear signal will always have PP = 1.0 and ML-BS = 100.
When you have a branch/taxon bipartition, a phylogenetic split, where PP >> ML-BS then it usually a signal issue in your underlying matrix: Either
1) a faint signal, very few sites supporting the split, hence, a higher chance that a BS-replicate eliminated those sites but PP remain high, because they do not resample the underlying data and the signal was lost (in this case no topological alternative receives meaningful support with ML-BS), or
2) actual signal conflict between concatenated gene regions (in this case there are two or more alternative receiving ample/subtractive support). For instance, in the perfect case if you have 20% of segregating sites strictly following a topology A and 80% strictly following a topology B, BS-ML will be split 20:80 for both alternatives but PP ~ 1.0, because if 80% of the segragating sites support topology B, there be a very high probability that B is correct and A wrong (when we infer a tree, we use algorithms that work under the assumption that there is only one single-correct tree that produced the entire data set)

To see how your PP and ML-BS relate to each other in total, you can use
a) the bipartition frequency mapping option in RAxML (option -f m; which gives you an x-y plot and computes the Pearson correlation coefficient)
b) investigate the bootstrap replicate sample and Bayesian sample using the consensus network approach implemented in SplitsTree (you can just open the RAxML_bootstrap and .t file, make sure you delete the burnin fraction, with SplitsTree; choose COUNT in the popping up menu to optain edge lengths that are proportionate to the support of the according split; and the updated Phangorn Package for R, https://peerj.com/preprints/2054; see vignettes for guidelines how to use the new network functions)

To have disparitate PP / ML-BS support for the branch after the root node is not uncommon and - to my experience - shows that you outgroup-inferred root is problematic (BS and PP react differently to ambiguous signals). Particular problematic are outgroups that are very distinct from your ingroup taxa (ingroup-outgroup branching artefacts). You can use RAxML for a quick test:
Step 1: Run an analysis without the outgroups
Step 2: Use the evolutionary placement algorithm implemented in RAxML (-f v) to find the optimal position of each outgroup taxon within the ingroup-only tree (there have been quite a bunch of posts on this and e.g. this paper: http://dx.doi.org/10.1080/14772000.2014.941037 -- if you have no access, try RG or Academia)

Cheers, Guido

[Alexandros Stamatakis]

since this apparently concerns the outgroup branch, could it be that
this is more of a tree visualization than a methodological issue?

please have a look at our recent preprint:

http://biorxiv.org/content/early/2015/12/25/035360

alexis

> <https://groups.google.com/d/topic/raxml/uzlNe8rtZE8/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to

> raxml+un...@googlegroups.com
> <mailto:raxml+un...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "raxml" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to raxml+un...@googlegroups.com
> <mailto:raxml+un...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Alexandros (Alexis) Stamatakis

Research Group Leader, Heidelberg Institute for Theoretical Studies
Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
Adjunct Professor, Dept. of Ecology and Evolutionary Biology, University
of Arizona at Tucson

www.exelixis-lab.org

[Michael Jowers]

Dear Guido,

Thank you so very much for your email and the detailed explanation. Indeed your reasoning makes perfect sense and reflects the findings I have been obtaining. I have run some further analyses and compared the data and it all seems to fall into place. Alexis paper is also most interesting concerning the outgroup support.

Thanks again and I hope that others in this forum can benefit form such useful comments.

Best

Michael

    raxml+unsubscribe@googlegroups.com
    <mailto:raxml+unsubscribe@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.


--
You received this message because you are subscribed to the Google
Groups "raxml" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to raxml+unsubscribe@googlegroups.com
<mailto:raxml+unsubscribe@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
Alexandros (Alexis) Stamatakis

Research Group Leader, Heidelberg Institute for Theoretical Studies
Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
Adjunct Professor, Dept. of Ecology and Evolutionary Biology, University
of Arizona at Tucson

www.exelixis-lab.org

--
You received this message because you are subscribed to a topic in the Google Groups "raxml" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/raxml/uzlNe8rtZE8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to raxml+unsubscribe@googlegroups.com.

[Grimm]

Am Donnerstag, 22. September 2016 14:14:41 UTC+2 schrieb Michael Jowers:

Dear Guido,

Thank you so very much for your email and the detailed explanation. Indeed your reasoning makes perfect sense and reflects the findings I have been obtaining. I have run some further analyses and compared the data and it all seems to fall into place. Alexis paper is also most interesting concerning the outgroup support.

I truly belief we should spend more time understand why we have no unambiguous support for a branch rather than trying to add more gene regions/delete taxa to get a fully resolved tree (well, there may be questions the latter is really needed for). With the fast bootstrapping implementation in RAxML, one can easily tear apart a multigene dataset to look where the signal comes from; and post-analysis processing (comparison) is speedy too these days with the functions implemented in Phangorn or other packages/programmes.
It can be fun, too (like dissambling the old fashioned alarm clock when you were a kid to see where the noise comes from) and there is a small, but increasing amount of reviewers appreciating to see a bit more than just two trees in a phylogenetic study.

My guess is that most PP vs BS conflicts resolve when those values are compared directly/mapped on the same tree, rather than the current standard of comparing the Bayesian maj-rule with the best-known ML tree. But I can't remember when I last stepped over a x-y bipartition plot in a paper or supplement. Alexi may have some on stock (?)

Thanks again and I hope that others in this forum can benefit form such useful comments.

Hope dies last :)