Problem with plot? or ape2ouch?

[kingaa]

Problem with plot? or ape2ouch?

[mbutler808]

One clue - the BEAST tree is rooted, whereas the IQTREE is unrooted. Will have to look into this.

[kingaa]

There have been no changes to ape2ouch. Perhaps the change to ouch::plot broke the recursion. Also possible that this behavior predates version 2.15-1....

[mbutler808]

Thank you. I will dig into it a bit more and report back. I can test it against 2.14 and also try exporting to newick and importing back in. I’m wondering if the issue is that sometimes the root node in ape has three rows in the edge matrix and sometimes only 2? Or if something about the beast nexus format is causing the problem

[mbutler808]

Hi @kingaa -- I tested under 2.14.1 and the issue is there too. I found a very small BEAST 12 taxon tree the reproduces the problem and narrowed it down to the node order. If I output the tree data to csv and then reorder the terminal taxa rows into the same order as in the ape tree plotted (post-traversal order), and recreate the ouchtree object, the plot is beautiful.

Here is a script that illustrates with the tree file input.

I donʻt know where to look for where the node numbering should be checked for the traversal order - in ouchtree()? Thank you. Marguerite
Archive 2.zip

[kingaa]

Brilliant! Good to know the problem doesn't come from the latest change! That would have been embarrassing. I think the plot code makes an unwarranted assumption about the ordering of the rows. That can be fixed fairly easily, I guess.

I won't have time to work on this for a few days at least. I think the node-numbering check you are looking for is inside arrange.tree, in the plot.R file. If you want to do more sleuthing, be my guest. If you've had enough, I will try to run this to ground once I get a few minutes.

I think the general idea of the fix should be to remove any dependence on the order of the rows in the ouch data frame. Nothing should depend on that. We may have to check codes in ouchtree, as well as brown and hansen just to make sure there are no assumptions made there. With the small examples you've put together, it should be easy, at least, to check whether any putative fixes are actually correct.

Thanks for your work on this!

[mbutler808]

OK - hereʻs something really weird. If I write out the BEAST tree with ape and read it in again -> ape2ouch -> plot with ouch, then itʻs fine!

prim <- read.nexus("Primates.MCC.tree")
write.tree(prim, "beast-ape-prim.tree")
prima <- read.tree("beast-ape-prim.tree")
oprima <- ape2ouch(prima)

plot(prima)
plot(oprima)

This only works in newick () format - nexus format throws an error when I try to write.nexus().

[mbutler808]

@kingaa sounds good.
I did sort the arrange.tree by node number to get the tree to plot correctly after the original ape2ouch conversion. This was because ape order is different than ouch order and the plot would be messed up. I see that now it only works for a particular traversal order. I didnʻt know what the yy order was natively. Iʻll think about it.

[mbutler808]

Hey @kingaa I am still wondering what is going on with this. When I was tinkering with arrange.tree, one thing I didnʻt know what what is the node order of yy? What seemed to work (for the ape trees) was to sort the result after the recursion by node number. That assumes the nodes are ordered in order of drawing on the plot, which is not always true.

So is a better strategy to save the original order of the nodes on entry to arrange.tree so that they can be sorted in that order to return? Will this return the correct vector for line in tree.plot.internal?

   yy <- arrange.tree(root,anc,term)

If I understood yy better then I might be able to fix this.
Thanks!
Marguerite

[kingaa]

Interesting. It appears that, in the problematic plot, the terminal taxa are in alphabetical order. I wonder where that's coming from.... Hard to tell with the big plot up above, but that does not appear to have the taxa in alphabetical order.

[kingaa]

I found the issue. I will push the fix in a little bit.

[kingaa]

@mbutler808, please check out version 2.16-1, just pushed. The plotting routines are quite a bit more streamlined. The order still matters, but the lineages will not be overlaid any more. Can you please check using the codes you have been using?

I wonder whether we want to do something like ladderize the tree? Not everyone wants that all the time, I suppose. I added a new, unexported function clade_size, which computes the size of the clade rooted at each node. This could be used to ladderize, if that is something we want.

[mbutler808]

Archive.zip
It works!!!! Thank you so much @kingaa!!
Yes, the code is STREAMLINED and beautiful!
What was the bug? I see that you moved the initial assignment of xx and yy outside of the loop through the levels, was that all you needed to do to keep xx and yy ordered the same wrt correspondence to node?
And you rewrote arrange tree so the terminal node is not passed, and basically itʻs only dealing with the position of y of the children, which is exactly the important info. So it makes no assumptions about order at all. Beautiful.

Iʻm going to suggest some edits to the graphical parameters to make the plot render more nicely. I hope you donʻt mind. One thing that is a bit annoying is that if you specify frame.plot=F in the call to plot, you get a warning because there are two ... internal to the function and one of them throws a warning. Thus the reason for one of the suggestions.

Thank you!
Marguerite

Example and input files in .zip

require(ape)
require(ouch)

prim <- read.nexus("Primates.MCC.tree")
plot(prim)
nodelabels()
prim$edge
str(prim)

oprim <- ape2ouch(prim)
plot(oprim, frame.plot=F)
tree.plot.internal(oprim, frame.plot=F)   # source function from plot.R along with is.root.node from ouchtree.R
tree.plot.internal(oprim, frame.plot=F)     # works!!

x <- read.nexus("consensus_beast.trees.nex")
ox <- ape2ouch(x)
plot(ox)
tree.plot.internal(ox)

x <- read.tree("consensus_beast.trees")
ox <- ape2ouch(x)
plot(ox)
tree.plot.internal(ox)

[mbutler808]

I think an option to ladderize would be a great addition. I have seen other packages do it as an optional argument, maybe ladderize=F, etc.