Generating an ultrametric tree + rooting issue

[Roey Angel]

I was wondering if there's a way to construct an ultrametric tree using RAxML (or at least to coerce one to look like it). I need the tree to be ultrametric for a downstream analysis.
Also I need the tree to be rooted (arbitrary - mid way, not biologically meaningful), is there a way to achieve this as well?

Thanks in advance
Roey

[Alexandros Stamatakis]

Hi Roey,

> I was wondering if there's a way to construct an ultrametric tree using
> RAxML (or at least to coerce one to look like it). I need the tree to be
> ultrametric for a downstream analysis.

Nope, but I'd encourage you to use DPPDIV by Tracy Heath, it's a Baysian
divergence time estimation tool that we recently optimized and
parallelized with Tracy.

> Also I need the tree to be rooted (arbitrary - mid way, not biologically
> meaningful), is there a way to achieve this as well?

Not with RAxML, but you could chose an arbitrary outgroup of course with
the -o option.

Also, my PhD student Fernando (on the CC) had implemented a mid-point
rooting algo at some point.

Fernando, do you think we could either integrate that code into RAxML or
provide it as stand alone code?

Alexis

>
> Thanks in advance
> Roey
>

--
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

[Fernando Izquierdo]

Hi all,

As far as I remember what we implemented was an algorithm to find the
most central node in terms of branch lengths, which was defined as the
inner node n that minimizes the variance of the 3 subtree lengths
{stl1, stl2, stl3} derived from n, where each stl was the sum of all
branch lengths included in that subtree.

We were not using this for rooting, but I guess this is somewhat
similar to the mid-point rooting, and I can find this code and make it
available in a fork of raxml (or merge it in the latest version) if
this is useful.

Cheers,
Fernando

[Roey Angel]

Hi Alexander and Fernando,
Thanks a lot for your answers. Yes I think such a feature will be useful.

Roey

[Alexandros Stamatakis]

the feature is implemented now, please see the commit message.

https://github.com/stamatak/standard-RAxML/commit/e3348e3fadaec503467af647fb329f3c4ad4602e

I built my own idiosyncratic rooting criterion.

Alexis

[anna papadopoulou]

Hi Alexis and Fernando,

that's really great that you've implemented this rooting feature in the latest version of RAxML!!

I am trying to use it on a bunch of large unrooted trees, but I am having

the following two problems:

a) I can't open the resulting trees in the standard tree viewing programs

(FigTree or Dendroscope), they complain that the tree is missing a ')'. Do

you have any clue which might be the problem and how I could to solve it?

b) Would it be any possible to apply this on a 'bipartitions' tree file,

and keep the bootstrap values on it after the rooting? when I try it on a

'bipartitions' file, the bootstrap values do not appear any more in the

resulting rooted tree

thanks a lot!

best wishes,

Anna

[Alexandros Stamatakis]

Gia sou Anna,

> that's really great that you've implemented this rooting feature in the
> latest version of RAxML!!

:-)

> I am trying to use it on a bunch of large unrooted trees, but I am having
> the following two problems:
> a) I can't open the resulting trees in the standard tree viewing programs
> (FigTree or Dendroscope), they complain that the tree is missing a ')'. Do
> you have any clue which might be the problem and how I could to solve it?

Yes, that was a problem with the tree printing routine which I fixed today.

> b) Would it be any possible to apply this on a 'bipartitions' tree file,
> and keep the bootstrap values on it after the rooting? when I try it on a
> 'bipartitions' file, the bootstrap values do not appear any more in the
> resulting rooted tree

Yes, I implemented this today as well, but please read the github commit
message prior to using it:

https://github.com/stamatak/standard-RAxML/commit/8794e6259822ad5e1a978daf1fb7e210fddabe92

here's the text:

"added the ability to parse trees with branch-labels (not node labels)
as displayed in the RAxML_bipartitionsBranchLabels.RUN_ID files in the
tree rooting option (-f I option) and display them on the rooted tree.
Note that, the branch label (representing the support) at the root will
be duplicated,that is, if I insert the root at an inner branch with a
support of say 68, a branch label with support 68 will be displayed on
each of the two branches descending from the root."

By the way, trees with branch labels (actually the correct way of
displaying support values which are always associated to
branches/splits/bipartitions of the tree) can be viewed with Dendroscope.

Let me know how that works.

All the best,

Alexis

>
> thanks a lot!
>
> best wishes,
>
> Anna
>
> On Monday, June 3, 2013 3:25:28 PM UTC+2, Roey Angel wrote:
>>
>> I was wondering if there's a way to construct an ultrametric tree using
>> RAxML (or at least to coerce one to look like it). I need the tree to be
>> ultrametric for a downstream analysis.
>> Also I need the tree to be rooted (arbitrary - mid way, not biologically
>> meaningful), is there a way to achieve this as well?
>>
>> Thanks in advance
>> Roey
>

[anna papadopoulou]

Hi Alexis,

Thank you very much for this! It seems to be working fine now, and all your explanations are very useful.

One general question: Could you explain briefly why you decided to use your 'own idiosyncratic rooting criterion' (based on the subtree lengths) instead of 'midpoint rooting' (based on the longest tip-to-tip path)? I understand there must be an advantage, I just want to make sure I can justify it correctly in a manuscript.

Also, in the commit message you say: "A branch with an optimal balance does not always exist!" What does this mean exactly and what happens in these cases? I want to incorporate this as part of a pipeline, and I need to make sure that it will work fine across any given tree.

Thank you very much for all your help,

all the best,

Anna

[Alexandros Stamatakis]

Hi Anna,

> Thank you very much for this! It seems to be working fine now, and all your
> explanations are very useful.

:-)

> One general question: Could you explain briefly why you decided to use your
> 'own idiosyncratic rooting criterion' (based on the subtree lengths)
> instead of 'midpoint rooting' (based on the longest tip-to-tip path)? I
> understand there must be an advantage, I just want to make sure I can
> justify it correctly in a manuscript.

Well, it roots the tree in a different way by not only looking at the
longest tip-tip distance, quite honestly I didn't give it much thought,
just following my intuition about how I'd do it.
Maybe you can come up with a good justification ;-)

> Also, in the commit message you say: "A branch with an optimal balance does
> not always exist!" What does this mean exactly and what happens in these
> cases? I want to incorporate this as part of a pipeline, and I need to make
> sure that it will work fine across any given tree.

It means that one is not always able to place the root on a branch of
the tree in a way such that LeftSubtreeLength - RightSubtreeLength = 0,
one can come up with a simple counter-example. In those cases we just
try to place the root such that ABS(LeftSubtreeLength -
RightSubtreeLength) is minimized.

Cheers,

Alexis

>
> Thank you very much for all your help,
>
> all the best,
>
> Anna
>

[Michael Weiß]

Dear Alexis,

concerning the new rooting option in RAxML: I just thought about your idea about balancing as best as possible the total branch lengths of the two subtrees induced by the rooting. However, imagine you found the 'true' tree for all known species in some organismic group (rooted with your new rooting option), and then just detect some more species that all belong to one of the two subtrees of this tree. After adding them to the tree, the position of the root might change --- at least if the new species are on long enough branches and if there is a high enough number of them.

Also, trees rooted with just one or two outgroup sequences (which is the dominating type of rooted tress in the literature I suspect) will not result from the new rooting option.

Both arguments make me feel that this new alternative rooting criterion (in contrast to midpoint rooting) may not be realistic in many cases. Am I wrong?

Cheers,

Michael

--
Dr. Michael Weiß
Associate Professor, Department of Biology
University of Tübingen
Auf der Morgenstelle 5
D-72076 Tübingen
Germany

Telephone: +49-7071-29-72608
http://www.uni-tuebingen.de/en/15267
http://tinyurl.com/9l3neon (Google Scholar)
http://tinyurl.com/akelqr5 (Thomson Reuters)
http://tinyurl.com/9lutm9t (ResearchGate)

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Alexandros Stamatakis]

Dear Michael,

> concerning the new rooting option in RAxML: I just thought about your idea about balancing as best as possible the total branch lengths of the two subtrees induced by the rooting.
> However, imagine you found the 'true' tree for all known species in some organismic group (rooted with your new rooting option), and then just detect some more species that all belong to one of the two subtrees of this tree.
> After adding them to the tree, the position of the root might change ---

Yes, of course, but this may happen regardless of the rooting algorithm
you chose.

> at least if the new species are on long enough branches and if there is a high enough number of them.
>
> Also, trees rooted with just one or two outgroup sequences (which is the dominating type of rooted tress in the literature I suspect) will not result from the new rooting option.

No, this rooting option is simply for rooting unrooted trees for which
no outgroup is available (for whatever reason).

> Both arguments make me feel that this new alternative rooting criterion (in contrast to midpoint rooting) may not be realistic in many cases. Am I wrong?

I am sure that midpoint rooting will also fail under specific
circumstances, but as I said, this is just one way of rooting trees.

Alexis

>
> Cheers,
>
> Michael

[anna papadopoulou]

Hi Alexis,

thanks a lot for your answers.

Can I ask you another question regarding a small practical issue?

when I apply this new rooting feature in RAxML, the trees I get seem to have an extra pair of parentheses around one of the two subtrees:

something like: ((clade1, clade2), ((clade3, clade4)));

instead of  ((clade1,clade2),(clade1,clade4));

Is there a specific reason for this?

The problem is that due to this extra pair of parentheses the resulting trees cannot be read by the read.tree function in R (ape), and by some other tree parsing scripts we are using.

Thanks a lot!

all the best,

Anna

[Alexandros Stamatakis]

Dear Anna,

Thanks for pointing this out, I just fixed it and pushed the new version
to github.

Alexis

[Anna Papadopoulou]

That's great, thank you so much Alexi!

Anna

--
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/Fsw5Z1sSR7A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to raxml+unsubscribe@googlegroups.com.