Running on empty

[Casey Dunn]

I'd like to "run on empty", i.e. not have the likelihood inform the posterior so I can just see the impact of priors. This is the equivalent of using the mcmc data=no flag in mrbayes.

Would the revbayes equivalent be to not clamp the data, eg comment out `seq.clamp(data)` from https://github.com/revbayes/revbayes/blob/master/examples/GTR_Gamma.Rev ?

[Michael Landis]

Yes, you can run MCMC under the prior like so

mymcmc.run(generations=30000, underPrior=true)

Setting that underPrior flag will essentially bypass computing probabilities for any "clamped" node -- i.e. nodes contributing to the model likelihood -- so the posterior equals the prior. One benefit of this is it speeds up MCMC quite a bit.

For RevBayes, there's a subtle reason why *not* clamping the data doesn't result in the prior equaling the posterior. All random variables in RevBayes are initialized with a value drawn from their underlying distribution. This is useful for simulation. But an unclamped variable will still have a specific initialized value whose probability is sensitive to other parameters in the model, and induces some (likely unintended) posterior density.

Hope this helps.

[Casey Dunn]

Hi Michael-

    Thanks, this is very helpful! I saw some odd posterior densities without clamping (a pi of [1, .25, .25, 0]), which is why I asked. Glad to know there is a specific mechanism for doing this.

[Casey Dunn]

It looks like the `.burnin()` method doesn't have a `underPrior` argument. My plan is to skip it, and just apply the burnin at the `mapTree` function. The potential issue is that this means I am also skipping the `tuningInterval` that is applied by the `.burnin()` method. Is that a problem?

Thanks,

    -C

[Michael Landis]

In general, you should not need a burn-in period if you are running under the prior in RevBayes. If you suspect something is fishy, you should be able to identify poorly mixed parameters in Tracer. Those parameters will exhibit low ESS values and with long episodes of constant value (stasis feels like the right word here).

Your suggestion to allow the burn-in to run under the prior is a simpler and safer solution. Will look into it.

--
You received this message because you are subscribed to the Google Groups "revbayes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to revbayes-user...@googlegroups.com.
To post to this group, send email to revbaye...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/revbayes-users/f139b9d9-265d-4063-9ca3-a244d996a29f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph Brown]

Seems like having a burnin with the prior-only would be beneficial. From analyses with MrBayes and BEAST under the prior it is often the case that the burnin in non-negligible. Casey's point about tuning seems important, too.

JWB

To view this discussion on the web visit https://groups.google.com/d/msgid/revbayes-users/56EC080F.6050605%40gmail.com.

[Michael Landis]

Yes, thanks for the correction. I was speaking too narrowly about my experience that the default tuning parameters are often good enough to mix over the relatively flat prior density. MCMC under the prior will still take time to reach stationarity, like Joseph points out.

On Friday, March 18, 2016 at 10:03:56 AM UTC-4, Joseph Brown wrote:

Seems like having a burnin with the prior-only would be beneficial. From analyses with MrBayes and BEAST under the prior it is often the case that the burnin in non-negligible. Casey's point about tuning seems important, too.

JWB

On 18 March 2016 at 09:52, Michael Landis <mla...@gmail.com> wrote:

In general, you should not need a burn-in period if you are running under the prior in RevBayes. If you suspect something is fishy, you should be able to identify poorly mixed parameters in Tracer. Those parameters will exhibit low ESS values and with long episodes of constant value (stasis feels like the right word here).

Your suggestion to allow the burn-in to run under the prior is a simpler and safer solution. Will look into it.

On 3/18/16 8:13 AM, Casey Dunn wrote:

It looks like the `.burnin()` method doesn't have a `underPrior` argument. My plan is to skip it, and just apply the burnin at the `mapTree` function. The potential issue is that this means I am also skipping the `tuningInterval` that is applied by the `.burnin()` method. Is that a problem?

Thanks,

    -C

On Friday, March 18, 2016 at 7:23:25 AM UTC-4, Casey Dunn wrote:

Hi Michael-

    Thanks, this is very helpful! I saw some odd posterior densities without clamping (a pi of [1, .25, .25, 0]), which is why I asked. Glad to know there is a specific mechanism for doing this.

On Thursday, March 17, 2016 at 4:51:13 PM UTC-4, Michael Landis wrote:

Yes, you can run MCMC under the prior like so

mymcmc.run(generations=30000, underPrior=true)

Setting that underPrior flag will essentially bypass computing probabilities for any "clamped" node -- i.e. nodes contributing to the model likelihood -- so the posterior equals the prior. One benefit of this is it speeds up MCMC quite a bit.

For RevBayes, there's a subtle reason why *not* clamping the data doesn't result in the prior equaling the posterior. All random variables in RevBayes are initialized with a value drawn from their underlying distribution. This is useful for simulation. But an unclamped variable will still have a specific initialized value whose probability is sensitive to other parameters in the model, and induces some (likely unintended) posterior density.

Hope this helps.

On Thursday, March 17, 2016 at 3:21:10 PM UTC-4, Casey Dunn wrote:

I'd like to "run on empty", i.e. not have the likelihood inform the posterior so I can just see the impact of priors. This is the equivalent of using the mcmc data=no flag in mrbayes.

Would the revbayes equivalent be to not clamp the data, eg comment out `seq.clamp(data)` from https://github.com/revbayes/revbayes/blob/master/examples/GTR_Gamma.Rev ?

--
You received this message because you are subscribed to the Google Groups "revbayes-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to revbayes-users+unsubscribe@googlegroups.com.
To post to this group, send email to revbayes-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/revbayes-users/f139b9d9-265d-4063-9ca3-a244d996a29f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "revbayes-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to revbayes-users+unsubscribe@googlegroups.com.
To post to this group, send email to revbayes-users@googlegroups.com.

[Michael Landis]

FYI, the development branch now supports `underPrior` as an option for `.burnin()`. The feature will be added to the master branch after more testing.

[Dunn, Casey]

Excellent - this will be a very helpful feature. Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to revbayes-user...@googlegroups.com.
To post to this group, send email to revbaye...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/revbayes-users/f139b9d9-265d-4063-9ca3-a244d996a29f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "revbayes-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to revbayes-user...@googlegroups.com.
To post to this group, send email to revbaye...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/revbayes-users/56EC080F.6050605%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

http://dunnlab.org

http://creaturecast.org

http://practicalcomputing.org