Analyses with multiple models get multiple clocks which are not handled well

[lmaurits]

Analyses with multiple models get multiple clocks which are not handled well

[lmaurits]

Since the overhaul of the clock system (i.e. the addition of [clock] sections and the introduction of the implicit [clock default] model), this issue has changed in nature somewhat. Now, all clocks by default share the one strict clock. This will cause problems if there are multiple [model]s with different rates of change, but I'm not too concerned because our (current) convention is that the default configuration is the simplest possible thing and is not expected to handle all issues.

If multiple clocks are specified for multiple models, the behaviour is now:

• If the tree branchlengths are non-arbitrary (e.g. we have calibration nodes), then the mean rate of both clocks are allowed to vary independently.
• If the tree branchlengths are arbitrary, then the mean rate of the "first" clock is fixed at 1.0, and the tree is scaled so that branchlengths are in units of expected substitutions for all models using that clock, and all "subsequent" clocks are allowed to vary independently.

The definition of "first" in the above is "the clock associated with the first model", and the definition of "first model" is "first according to the following code":

model_sections = [s for s in p.sections() if s.lower().startswith("model")]

I would like to believe that this means the "first" clock is the one which occurs first in the .conf file, but I haven't looked into the implementation of ConfigParser so I don't guarantee this.

I will update the output of --verbose to make explicit what it's doing, and extend the configuration of [clock] sections to give users more explicit control over this.

Everything I said in the first comment on this issue about setting the mean of all clocks to 1.0 is nonsense.

[lmaurits]

Okay, the user can now use estimate_mean = True or estimate_mean = False in a [clock] section to explicit control whether a clock's mean rate is estimated or fixed to 1.0. Their instructions will be respected in all cases. If there are any [clock]s for which the user did not give explicit instructions, BEASTling will estimate means for them, unless the tree's branchlengths are arbitrary and the user did not specify any non-estimated clocks, in which case BEASTling will fix exactly one clock at 1.0 and inform the user which one was fixed via a --verbose message. If the user doesn't like what BEASTling's automagic does, they can explicitly specify whatever alternative they like.