Open davidcerny opened 2 months ago
Hi David,
I think I came across this error before. The reason is that mrbayes has very strict checking of the times, making it hard to satisfy the criterion. I was able to do it by using 10 decimals ( see the attached example ). But otherwise I would just comment out the checking code and recompile, if you are confident about the input tree.
In the long run, it would be nice if someone could refine the checking code so that people would not struggle with fixing the tree.
I wanted to run an FBD analysis where both the topology and node times (and, by extension, temporal branch lengths as well) are fixed to a user-specified tree. While fixing the topology is simple enough, fixing the clock (temporal) branch lengths only appears to be possible for ultrametric trees.
What is the current observed behaviour?
For every fossil tip, I get a warning like this one:
followed by:
This is despite the fact that the branch lengths in the user tree do satisfy all the tip calibrations – I checked.
It is of course still possible to fix node times by specifying
propset NodesliderClock(V)$prob = 0;
, but as far as I can tell, this does not fix them to the values from the user-supplied tree.What is the expected/wanted behaviour?
As long as
myTree
satisfies all the tip calibrations, it should be possible to use theprset brlenspr=clock:fixed(myTree);
command to run an FBD analysis with fixed node times.How may we reproduce this bug?
Execute this Nexus file.
Would you be able to compile and run MrBayes to test fixes to this bug?
git
and how to compile MrBayes.What is the environment that you run MrBayes in?
develop
branch (e7b8431)Version
command in MrBayes below: