In this chapter we will have a look at interpreting the output of an MCMC analysis. At the end of a BEAST run, information is printed to the screen, and saved in trace log and tree log files. This chapter considers how to interpret the screen and trace log, while the next chapter deals with tree logs. We have a look at how to use the trace log to compare different models, and diagnose problems when a chain does not converge. As you will see, we emphasise comparing posterior samples with samples from the prior, since you want to be aware whether the outcome of your analysis is due to the data or a result of the priors used in the analysis.

Interpreting BEAST screen log output: At the end of a BEAST run, some information is printed to screen (see listing on page 88) detailing how well the operators performed. Next to each operator in the analysis, the performance summary shows the number of times an operator was selected, accepted and rejected. If the acceptance probability is low (<0.1) or very low (<0.01) this may be an indication that either the chain did not mix very well, or that the tuning parameters for the operator were not appropriate for this analysis. BEAST provides some suggestions to help with the latter case. Note that a low acceptance rate does not necessarily mean that the operator is not appropriately parameterised. For example, when the sequence alignment data strongly support one particular topology, operators that make large changes to the topology (like the wide exchange operator) will almost always be rejected. So, some common sense is required in interpreting low acceptance rates.

If the acceptance rate is high (>0.5), this indicates that the operator is probably making jumps that are too small, and BEAST may produce a suggestion to change a parameter setting for the operator. The exception to this are operators that use the Gibbs distribution (Geman and Geman 1984), which are generally efficient and always accepted.

For relaxed clock models, if the uniform operator on the branch-rate categories parameter has a good acceptance probability (say >0.1) then you do not need the random walk integer operator on branch-rate categories. You could just remove it completely and increase the weight on the uniform operator on branch-rate categories.