Hi Alina. Since you mentioned some functions of phytools, I thought it might be helpful to describe what each function is actually doing:
1) The function ls.consensus computes a least-squares (LS) consensus tree. This is the LS tree on the average patristic distance matrix of the input trees, as described by Lapointe & Cucumel (1997). This is a consensus method, but it has been criticized for not possessing what I believe is referred to as the 'Pareto' property - meaning, in this case, that the consensus tree can include relationships not present in any input tree! (In practice, this is probably rare for real empirical distributions of trees.) In general, the resultant tree will usually be completely resolved and if all input trees are ultrametric, the output tree will also be ultrametric. (Also see: http://blog.phytools.org/2016/04/average-trees-and-maximum-clade.html.) 2) The function averageTree trees to find the tree with the minimum sum of squared distances to all the trees in a set. The tree is not necessarily a member of the set. Any of a number of different distance criteria can be used; however, if the distance criterion selected does not use branch lengths (e.g., Robinson-Foulds distance) then the output tree will also not have branch lengths. (Also see: http://blog.phytools.org/2016/04/consensus-methods-and-computing-average.html.) 3) Finally, the function consensus.edges computes consensus edge lengths based on a set of input trees with edge lengths and a consensus topology. By default, this function computes the average edge lengths across all trees in which each edge of the consensus topology is present. The user can decide what to do if an edge is absent in a given input tree. The tree can be ignored, and thus contribute nothing to the consensus edge length for that particular edge, or the edge length for that tree can be set to zero. This function has a third mode, which is to merely compute the consensus non-negative least squares edge lengths on the user-supplied consensus tree. If all the input trees are ultrametric, then the computed tree will also be ultrametric. Note that this is difference from just using ls.consensus because in consensus.edges the LS edge lengths are computed on a fixed tree, whereas in ls.consensus we optimize both the topology and edge lengths given a set of trees. (Also see: http://blog.phytools.org/2016/03/method-to-compute-consensus-edge.html.) maxCladeCred was also mentioned by another list member. This is a function of phangorn that finds the tree (or trees?) in the input set with the highest total clade probability. This is done by going clade by clade in each tree of a set, and computing the relative frequencies with which each clade is represented across the set (these are the posterior probabilities for each clade), multiplying the clade relative frequencies for each tree, and then selecting the tree with the highest product. Since this procedure merely permits us to select a tree or trees from our posterior distribution, our tree should generally be fully resolved and ultrametric if the trees in our input set are fully resolved and ultrametric. Note also that in a Bayesian posterior sample our maximum clade credibility (MCC) tree will usually be represented many times. If we find all instances of the MCC tree in our set, and all instances are ultrametric, then computing the average edge lengths across this set (e.g., using consensus.edges) will also produce a tree that is ultrametric. All the best, Liam Liam J. Revell Associate Professor, University of Massachusetts Boston Profesor Asistente, Universidad Católica de la Ssma Concepción web: http://faculty.umb.edu/liam.revell/, http://www.phytools.org On 1/24/2019 6:14 PM, Alina van dijk wrote: > Hi everyone, > > Thanks Emmanuel and Joseph for sharing your thoughts! > Emmanuel, today I tried multi2di and it works. But, if I understand > correctly, this function transforms the dichotomies with branches of length > zero. So for me, in fact, doesn't solve the politomy. Right? > Joseph, I'm only a begginer with R and this program already gives me a lot > of headache. > It drives me crazy think in another program... hahahha > Just kidding! :) > But, nice to know that I have a plan B! > I will take a look! > > Thanks in advance, > Best Regards, > > Alina > > > Em qua, 23 de jan de 2019 às 16:29, Emmanuel Paradis < > emmanuel.para...@ird.fr> escreveu: > >> Hi Alina, >> >> Did you try multi2di() to remove polytomies? >> >> Best, >> >> Emmanuel >> >> Le 23/01/2019 à 17:41, Alina van dijk a écrit : >>> Hi everyone, >>> >>> My name is Alina, I'm attending master degree in ecology and I have a >>> little problem with my consensus phylogeny. I used 1000 phylogeny of >>> birdtree to construct the consensus tree but now I need to insert the >> dates >>> in this consensus tree. >>> >>> To accomplish this idea, I tried different methods: >> consensustree<-averageTree >>> (tree,method="symmetric.difference") but the result is a consensus tree >> in >>> topology, binary and rooted but not ultrametric. For this problem I used >>> consensus_tree_ultrametric >>> <-compute.brlen(consensustree,method="Grafen",power=1), but the edge >>> lengths was altered. >>> >>> So, I used another method to make a consensus tree using phytools >>> consensustree_another_method <- consensus.edges(multiphylo,method = >>> "mean.edge") as a result, a ultrametric tree, rooted with consensus edges >>> lengths, but have polytomies :( >>> >>> I also tried using phylobase , proposed by Brian O'Meara in this link: >>> >> https://grokbase.com/t/r/r-sig-phylo/12bn9x5gv4/why-no-branch-lengths-on-consensus-trees >>> , >>> but as a result, my consensus tree wasn´t ultrametric and the >>> transformation also altered the edge lengths. >>> >>> I only need to insert the dates based on the trees dated by Jetz in this >>> consensus tree and as result, an ultrametric tree, with consensus edges >>> lengths and no polytomy. >>> >>> Does anyone know how to solve that problem? >>> >>> Thanks in advance, >>> Best Regards, >>> >>> Alina >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-sig-phylo mailing list - R-sig-phylo@r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-phylo >>> Searchable archive at >> http://www.mail-archive.com/r-sig-phylo@r-project.org/ >>> >>> >>> Pour nous remonter une erreur de filtrage, veuillez vous rendre ici : >> http://f.security-mail.net/VKQxzoa2 >>> >>> >> > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-phylo mailing list - R-sig-phylo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > Searchable archive at http://www.mail-archive.com/r-sig-phylo@r-project.org/ > _______________________________________________ R-sig-phylo mailing list - R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo Searchable archive at http://www.mail-archive.com/r-sig-phylo@r-project.org/
