BEAST tree not reading as ultrametric in R - but it is

[Mark Hanson]

Hi all,

I have the bizarre experience of using ape to read.nexus() and load a BEAST tree which was is.ultrametric() = TRUE at first loading, but somehow without changing anything is now is.ultrametric() = FALSE on second loading. Tree was prepared in FigTree and exported as .nexus and also as .newick to test both - same error with both. I have no explanation for how this lack of reproducibility works, but I do have an equally baffled witness! Also just to head it off: yes, the tree is ultrametric visually.

From talking to others, it sounds like this could be down to how ape loads the branch lengths and/or posteriors, where each branch length is rounded at a given decimal place such that the total length of an extant tip might be 1.0000001 for one branch and 1.0000000 for another - or something like that? So ultimately it thinks they're not equal branch lengths to tips. As I understand, this is also what force.ultrametric() is for...

Rather than force.ultrametric(), I'd prefer to just find a way to load and export the tree in FigTree such that it's guaranteed to be read as ultrametric each time. Does anyone have experience with this issue? Does anyone have any ideas? Thanks!

[Luke Baton]

Mark,

I have also had similar problems in the past... Perhaps the following might be of interest/use: http://blog.phytools.org/2016/08/fixing-ultrametric-tree-whose-edges-are.html

Best wishes, Luke.

[Omar Idris]

If your file was from BEAST then you stated you loaded it on R and checked? Then you prepared it? In Fig. If so check the precision of Fig export and adjust decimal to 12. 

Sent from my iPhone

On Mar 26, 2025, at 4:09 PM, Mark Hanson <dipte...@gmail.com> wrote:

Hi all,

I have the bizarre experience of using ape to read.nexus() and load a BEAST tree which was is.ultrametric() = TRUE at first loading, but somehow without changing anything is now is.ultrametric() = FALSE on second loading. Tree was prepared in FigTree and exported as .nexus and also as .newick to test both - same error with both. I have no explanation for how this lack of reproducibility works, but I do have an equally baffled witness! Also just to head it off: yes, the tree is ultrametric visually.

From talking to others, it sounds like this could be down to how ape loads the branch lengths and/or posteriors, where each branch length is rounded at a given decimal place such that the total length of an extant tip might be 1.0000001 for one branch and 1.0000000 for another - or something like that? So ultimately it thinks they're not equal branch lengths to tips. As I understand, this is also what force.ultrametric() is for...

Rather than force.ultrametric(), I'd prefer to just find a way to load and export the tree in FigTree such that it's guaranteed to be read as ultrametric each time. Does anyone have experience with this issue? Does anyone have any ideas? Thanks!

--
You received this message because you are subscribed to the Google Groups "beast-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beast-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beast-users/39070fec-2871-4640-aa13-1f58358289e5n%40googlegroups.com.

[Mark Hanson]

Thanks! Useful link. Weirdly my nlss tree did affect my branch lengths in an imperfect way ( corr = .995), but I learned through this that force.ultrametric() has an option for nlss as the method, and this implementation worked nicely for me and the suggestion to check branch length correlations gives that bit of confidence that I know what I'm doing precisely.

If anyone finds this discussion, I'd try force.ultrametric(, method="nlss")

https://www.rdocumentation.org/packages/phytools/versions/2.4-4/topics/force.ultrametric

[Mark Hanson]

Thanks for response. Tree made in BEAST, loaded in then exported from FigTree, then loaded in R.

force.ultrametric(, method = "nlss") 

and also to check the correlation of branches/tips between the old tree and new tree.