[alexeid]

Stopgap for #200 before the release: the BEAUti templates (Standard.xml for the Yule prior, TreePriors.xml for the other tree priors) start BactrianSubtreeSlide at size="0.01" instead of "1.0".

Why

The size is measured in tree-height units. In example runs it tunes to:

• about 0.006–0.008 on substitution-scale trees (root height ≈ 0.06);
• 0.4–2.5 on time-scaled trees (root height 6–100).

So 1.0 is about 100× too big for a typical clock-rate-1 analysis, and tuning can't recover from that (#200). From 1.0, testCoalescent's slide sticks at 0.029 with 1.4% acceptance, against an optimum of 0.0083 at the 0.3 target.

Starting too small costs much less, because tuning grows the size far faster than it shrinks it. On testYuleCalibrated (optimum ≈ 2.0), a start of 0.01 reaches 1.6 within 1M steps.

Starting from the tree's own scale (about 0.5 · H/√nodeCount) is the better fix. It's in #200 for after the release.

Testing

BeautiSimpleTest and SimpleTreePriorTest pass. They build analyses from these templates, but they check operator IDs, not sizes.

[walterxie]

PR #201 doesn't break anything in BEAUti, and for the most common case it's a clear improvement. Its effect is to move the range of tree sizes where tuning fails, not to remove it. These are the problems it causes or leaves:

1. Trees with large height values now tune very slowly. This is the main new problem. Tuning grows the size by at most a factor of about e^(0.7·ln n) after n operator calls, so reaching a large optimum from 0.01 takes a long time. These are best-case numbers:

Tree (root height)	Optimum size	Slide calls needed	Roughly MCMC steps
~10 (testYuleCalibrated, Myr scale)	~2	~1,100	~10⁴, fine
~10³ (for example days)	~20	~3×10⁴	~3×10⁵
~10⁴ (for example years)	~200	~8×10⁵	~8×10⁶
~10⁵ years	~2000	~2×10⁷	~2×10⁸: in practice it never gets there
Dated analyses in years (ancient DNA, phylogeography) are where a user would hit this. The results aren't wrong; the slide just makes tiny moves, so the tree mixes more slowly and relies on the other tree operators.

2. Very shallow trees fail the old way. On a substitution-scale tree with root ~10⁻³ (low-diversity data, clock rate 1), the optimum is about 10⁻⁴. That's 100× below 0.01, and shrinking is slow: at least 2.6×10⁶ calls. This is the same "can't recover" failure as Auto-tuning can't recover from a step size that starts too large (1/n gain) #200, now at a smaller scale.
3. No tuning means the slide stays at 0.01. If the user turns off optimise on the operator, or autoOptimize on the run, the size never changes. 0.01 is far too small for any time-scaled tree.
4. The defaults now disagree. BactrianSubtreeSlide's own default (and its input description) is still size = 1.0. Hand-written XML and converted examples, including Convert 12 BEAST2 examples to BEAST3 (batch 2); ship SeqGen examples in beast-fx #204's, get 1.0, while BEAUti-made analyses get 0.01.
5. No test checks the new value. As the PR says, BeautiSimpleTest and SimpleTreePriorTest check operator IDs, not sizes, so nothing would catch a regression.