Someone (at the biohackathon) was trying out the pipeline and he created a list of Primate species with each species from a different family. This uncovered bug #80 (now fixed), and another one: because all species were now interpreted as monotypic, the end result was that the taxon set for the backbone and for clade0 are the same. This resulted in the code visiting a "fatal" branch: https://github.com/naturalis/supersmart/blob/master/lib/Bio/Phylo/PhyLoTA/Service/TreeService.pm#L873 - i.e.:
Something goes wrong here: MRCA of exemplar species " . join(',', map{$_->id} @exemplars) . " in backbone is the backbone root!"
It is not so obvious how to proceed. We could do a test to see if the backbone taxa and the clade taxa are the same and note that this is so in a message to the user. We could then decide that the clade tree is probably better quality than the backbone and return that. But then the "grafted" end result is no longer calibrated. Maybe this is OK, but this should be explained very clearly, among others in the FAQ.
rvosa
commented
9 years ago
Someone (at the biohackathon) was trying out the pipeline and he created a list of Primate species with each species from a different family. This uncovered bug #80 (now fixed), and another one: because all species were now interpreted as monotypic, the end result was that the taxon set for the backbone and for clade0 are the same. This resulted in the code visiting a "fatal" branch: https://github.com/naturalis/supersmart/blob/master/lib/Bio/Phylo/PhyLoTA/Service/TreeService.pm#L873 - i.e.:
It is not so obvious how to proceed. We could do a test to see if the backbone taxa and the clade taxa are the same and note that this is so in a message to the user. We could then decide that the clade tree is probably better quality than the backbone and return that. But then the "grafted" end result is no longer calibrated. Maybe this is OK, but this should be explained very clearly, among others in the FAQ.