Bug in BEAUti which prevents it from emitting the updown operator in some cases, which can slow convergence

[GoogleCodeExporter]

In a post on low ESS values for *BEAST analyses, Heled commented "There is a 
bug in BEAUti which prevents it from emitting the updown operator in some 
cases, which can slow convergence." which indicates to me that the operators 
should be included for *BEAST analyses, but need to be added into the xml 
manually.

So, for those who are interested in improving ESS values and convergence of the 
species tree parameters, here is the code I have added to my xml files to add 
in the up/down operators that are no longer output by BEAUti. This should be 
added to the operators section of the xml.

        <upDownOperator scaleFactor="0.75" weight="30">
            <up>
                <parameter idref="species.yule.birthRate"/>
            </up>
            <down></down>
        </upDownOperator>
        <upDownOperator scaleFactor="0.75" weight="3">
            <up></up>
            <down><speciesTree idref="sptree"/></down>
        </upDownOperator>
        <upDownOperator scaleFactor="0.75" weight="3">
            <up></up>
            <down><parameter idref="species.popMean"/></down>
        </upDownOperator>
        <upDownOperator scaleFactor="0.75" weight="3">
            <up></up>
            <down><parameter idref="speciesTree.splitPopSize"/></down>
        </upDownOperator>

You may need to change the parameter idrefs depending on your particular xml 
code. This is for the Yule species tree prior, if you use the birth death prior 
the idref would be <parameter idref="species.birthDeath.meanGrowthRate"/>.

 I have split the parameters so they each have their own operator, I don't know if this is better or different than doing the following:

<upDownOperator scaleFactor="0.75" weight="3">
            <up>
                <parameter idref="species.yule.birthRate"/>
            </up>
            <down>
   <speciesTree idref="sptree"/>
   <parameter idref="species.popMean"/>
   <parameter idref="speciesTree.splitPopSize"/> 
   </down>
        </upDownOperator>

I decided to split them because other parameters that were in a single up/down 
operator in previous releases of BEAUti (i.e. 
geneX.treeModel.allInternalNodeHeights) have their own operator in newer 
version of BEAUti. The transition seemed to be around BEAUti 1.7.2 where the 
allinternalNodeHeights up/down operators were written to the xml file twice in 
each format, grouped into one up or down and split into their own 
upDownOperators.

I hope that adding these operators helps others with mixing in their analyses.

Original issue reported on code.google.com by ramb...@gmail.com on 17 Dec 2013 at 11:56

[GoogleCodeExporter]

Adding all the <upDownOperators> with only one parameter is the equivalent of 
just adding extra scale operators for these parameters. This suggests the 
weights of these operators should be increased by default. Need to check if the 
updown interation of these parameters would also help.

Original comment by ramb...@gmail.com on 18 Dec 2013 at 12:10

[GoogleCodeExporter]

The issue is not with the "<upDownOperators> with only one parameter".

What is missing is the *combined*  upDownOperator, which includes the species 
tree, all gene trees and all the relevant rates (birth death, pop sizes and 
gene clock rates).

Original comment by jhe...@gmail.com on 18 Dec 2013 at 12:16

[GoogleCodeExporter]

But the single-parameter operators are what the user claimed improved mixing. 
It may be worth increasing the weights of these too? I think these will mostly 
be cheap operators to do (in terms of what needs to be reevaluated)? No harm in 
adding the full updown back in (it isn't clear how it got lost in the first 
place).

Original comment by ramb...@gmail.com on 18 Dec 2013 at 12:22

[GoogleCodeExporter]

Increasing the weight of the "species-tree" operators may hurt analysis with a 
smaller number of loci. Ideally the overall weights should be a some fixed 
ratio (say 20%) of the total operators weight. We are trying to resolve this in 
BEAST2 by introducing an "operators block" which can have a relative weight to 
the other "blocks".

Original comment by jhe...@gmail.com on 18 Dec 2013 at 12:45

[GoogleCodeExporter]

Original comment by ramb...@gmail.com on 18 Dec 2013 at 7:12

• Changed state: WontFix