bbcalibrate dies sometimes

[rvosa]

The scenario is as follows:

• we create a set of trees, either by bootstrapping or mcmc
• we try to reroot these using either taxonomy or outgroup, but this sometimes silently "fails" if there is a lot of non-monophyly, either of the outgroup or over the entire tree if we use taxonomy
• we can then not place the calibration points, so treePL dies

The cheat fix would be to throw out these trees, but this would artificially inflate support values and narrow age ranges on nodes. The honest fix would be to calibrate the whole tree on whichever is the oldest calibration point. Then, when we build a consensus we will have broadened the age ranges and lowered the support values.

[rvosa]

If rooting works, which it does much better since https://github.com/naturalis/supersmart/commit/906cf4c9c0daba634b5c14406167a1b998885b8d this could only be an issue if not a single calibration point is found. So far this hasn't been the case.

[rvosa]

Nope, still dying. There are apparently unpredictable combinations of calibration points that cause treePL to die. Both @hettling and @rvosa have tried (and failed) to understand when and how this happens but it is not obvious. The best we can do is to tell users to reconsider their calibration points, which is what we do as of f0def4a78d7bb9a69ac6d75e88f5a63b922b196a

[rvosa]

Thanks to @blackrim's better attention for what we've been doing than our own (see https://github.com/blackrim/treePL/issues/16) we have now uncovered that actually we sometimes define multiple, incompatible age ranges for the same node. This can happen because we initially define fossils as belonging to the crown or stem of some higher taxon.

What we used to do was simply get all the putative members of that higher taxon in relation to our focal tree and define the MRCA that way. Of course if 1) those putative members are not actually monophyletic, and 2) their MRCA is identical to the MRCA of some other calibration point, we end up feeding treePL with data that it can't make sense out (nor should it).

Our seemingly reasonable solution for this is now to detect instances of multiple calibrations speaking to the same node, and then picking the oldest (i.e. most inclusive) on. This is the behavior as of commit fe2e0d3d2cef215d88f7d3ecdeca33a92de7dd5f