[BUG] `TreeTools::Consensus()` unexpectedly generates incorrect strict consensus trees, unlike `ape::consensus`

[HS6986]

Description of the bug
When running TreeTools v1.13.0, I've discovered that TreeTools::Consensus() generates incorrect strict consensus trees on certain trees. I don't know the conditions of trees in which this bug occurs. This bug does not seem to occur with ape::consensus. This probably affects the analyses I have been conducting in my unpublished research, which frequently used TreeTools::ConsensusWithout().

How to reproduce the bug
Here are 4 subsampled jackknife trees of ones generated with my reduced version of the Dunn et al. (2022) dataset whose fossil taxa have been removed. Multiple topological constraints, including Staurozoa (in the trees, Calvadosia + Lucernaria + Haliclystus) and Myostaurida (in the trees, Lucernaria + Haliclystus) (Miranda et al., 2016), have been set. This is a code to reproduce the bug:

library("TreeTools")
library("ape")

trees4 <- read.tree("Trees4.trees")
par(mar = rep(0.25, 4), cex = 0.75)

cons3 <- consensus(trees4[1:3], p = 1)
plot(cons3)
Cons3 <- Consensus(trees4[1:3], p = 1)
plot(Cons3)
cons4 <- consensus(trees4, p = 1)
plot(cons4)
Cons4 <- Consensus(trees4, p = 1)
plot(Cons4)

cons3, Cons3, and cons4 are correct strict consensus trees, but Cons4 is a incorrect strict consensus tree, in which the three staurozoans are unexpectedly resolved in a nonexistent polytomy.

[ms609]

Thanks for the report, I'll look into this next week.

[HS6986]

Thank you for your reply.

I've realized that I made an unbelievably careless mistake in the code and provided exemplar trees that don't cause the intended problematic behavior. I apologize for my carelessness. I've correctly updated the code and the trees.

[ms609]

This seems to occur because the position of the root differs between trees[1:2] and trees[3:4].

Try:

cons4 <- consensus(trees4, p = 1)
plot(cons4)
Cons4 <- Consensus(RootTree(trees4, c("Calvadosia", "Lucernaria", "Haliclystus")), p = 1)
plot(Cons4)

?Consensus purports to return an object of class phylo, rooted as in the first entry of trees. ?ape::consensus details a rooted parameter that controls whether trees are treated as rooted.

[HS6986]

Thank you for your response.

Certainly, the code you provided worked correctly. However, why does Cons3 <- Consensus(trees4[1:3], p = 1) work well while Cons4 <- Consensus(trees4, p = 1) does not? The trees trees4[3] and trees4[4] seems to be completely identical. I don't think the fact you provided—TreeTools::Consensus purports to return an object of class phylo, rooted as in the first entry of trees—accounts for this issue. I believe the cause may lie elsewhere.

Please do not hesitate to let me know if there are any fundamental misunderstandings in my reasoning.

Thank you very much for your time and support.

[HS6986]

I have found one interesting behavior that may contribute to resolving this potential issue.

While the strict consensus of trees4 calculated using TreeSearch::EasyTrees() shows correct bipartitions within Staurozoa, that calculated using the script output by TreeSearch::EasyTrees() shows an incorrect basal polytomy within Staurozoa. However, both the strict consensus trees incorrectly mark the positions of the three staurozoan taxa unstable.

Here are the script and tree file output by TreeSearch::EasyTrees().

Thank you for your time and support.

[ms609]

Thanks for the further example. It'll probably take a few hours for me to re-familiarize myself with the code and dig into this – and it might be a few days before there's a suitably-sized gap in my schedule. If you have the opportunity, it would help to have a minimal reproducible example – i.e. with the lowest number of taxa for which the unexpected behaviour can be observed.

[HS6986]

Thank you for your response.

By simply dropping the tips other than the three staurozoan taxa and one outgroup (Placozoa) and reducing the number of the trees, I was able to create a minimal reproducible example for this issue. The number of the trees are three, and they consist of four tips.

The problematic behavior was confirmed with almost the same code I initially presented, and TreeSearch::EasyTrees() seems to be able to calculate the correct strict consensus.

Here are the R script and trees.

I deeply appreciate your time and support.

[ms609]

The problem doesn't occur if the trees are supplied in preorder, so I've adapted Consensus() to reorder the trees before computing the consensus (#171). This is perhaps not the most computationally efficient fix – if it becomes a bottleneck in future then a more detailed interrogation of the underlying consensus_tree() may allow a more performant solution. Hopefully this fixes the issues you've encountered – let me know if not!

[HS6986]

Thank you for your reply and for fixing the issue!

I am concerned that this issue may have affected the results of previous studies. It might be worthwhile to recalculate the strict consensus trees.

I deeply appreciate your time and support.