Unexpected prior age distribution of uncalibrated nodes with the Calibrated Yule model

268 views
Skip to first unread message

Guillaume L

unread,
Feb 19, 2024, 1:53:51 PMFeb 19
to beast-users
Hi all,

I made the mistake of using improper rate priors with the 'Calibrated Yule model' and have now found how to parameterize them, but it puzzles me a little, so I would like to request some additional explanations :)

I am using Beast 2.6.6. In my dating analysis, I initially thought that the Yule model would be appropriate, and computationally interesting because it has only one parameter (not the case in fact). I therefore used the “Calibrated Yule Model” as advised.

I have 21 species and I set two informative calibrations near the root.

When sampling from the prior, the age distribution on uncalibrated nodes seemed wrong to me: instead of being somewhat “uniformly” distributed in time, these nodes were all stacked against the present (see picture).
beastS_hky_sampleprior_strictclock_rateupperlim_onepartition.annot.tree.png

This also occured when I set a strict clock model, and even with an upper limit to its rate. However when changing the “tree prior” to basic 'Yule' (default), Birth-Death or Coalescent, I get reasonable age distributions (see second picture).
beastS_hky_sampleprior_strictclock_rateupperlim_onepartition_BirthDeath.annot.tree.png

I ended up finding that the prior on the clock rate *and* the birth rate *have to* be specified, and be different from the uniform distribution. In fact the tutorial http://beast2-dev.github.io/beast-docs/beast2/DivergenceDating/DivergenceDatingTutorial.html does indicate it clearly.

What puzzles me is, why is this only affecting the “Calibrated Yule Prior”, and not the other models like the Birth-Death?

Wouldn't it be reasonable to emit an explicit warning in Beast about these improper priors?

Thanks in advance,

best,

Guillaume

Alexei Drummond

unread,
Feb 19, 2024, 7:01:46 PMFeb 19
to beast-users
Hi Guillaume,

I would certainly be happy to vote for BEAUti refusing to allow improper priors! :)

It is relatively easy to explain the difference in your case though:

(1) Calibrated Yule prior with improper birth rate prior

In a “Calibrated Yule prior” (sensu Heled and Drummond 2012) the calibrated nodes are formally removed (i.e. conditioned on) so that the ages of your calibrations tell you nothing about the speciation/birth rate. So given you say nothing a priori about the speciation rate either through a proper prior, or through calibration times, the birth rate could be as high as possible. Averaging over every possible extremely high speciation rate will give you very small divergence times for every node that is not calibrated.

(2) Standard Yule prior.

In the “standard" Yule prior, the calibrated nodes are not formally removed from the Yule prior, so they are subject to two different densities: the calibration density and the Yule density. Because of this you effectively “learn” about the birth rate from the calibration ages themselves (since having the common ancestor of a clade of size X be T years ago gives some information about probable birth rates). So this will translate to information about birth rate and therefore other node ages. This may seem on the surface to be a useful property, but it really depends on how you view calibrations. Are they data to do inference from, or knowledge to condition on? If they are the former, than this approach makes some sense, though it is still not formally correct even under that interpretation.

For details and additional discussion check out these two publications:

Calibrated Yule:

Joseph Heled, Alexei J. Drummond, Calibrated Tree Priors for Relaxed Phylogenetics and Divergence Time Estimation, Systematic Biology, Volume 61, Issue 1, January 2012, Pages 138–149, https://doi.org/10.1093/sysbio/syr087

Calibrated Birth-death and multiple calibrations:

Joseph Heled, Alexei J. Drummond, Calibrated Birth–Death Phylogenetic Time-Tree Priors for Bayesian Inference, Systematic Biology, Volume 64, Issue 3, May 2015, Pages 369–383, https://doi.org/10.1093/sysbio/syu089

Cheers
Alexei

> On 20/02/2024, at 7:46 AM, Guillaume L <guill....@gmail.com> wrote:
>
> Hi all,
>
> I made the mistake of using improper rate priors with the 'Calibrated Yule model' and have now found how to parameterize them, but it puzzles me a little, so I would like to request some additional explanations :)
>
> I am using Beast 2.6.6. In my dating analysis, I initially thought that the Yule model would be appropriate, and computationally interesting because it has only one parameter (not the case in fact). I therefore used the “Calibrated Yule Model” as advised.
>
> I have 21 species and I set two informative calibrations near the root.
>
> When sampling from the prior, the age distribution on uncalibrated nodes seemed wrong to me: instead of being somewhat “uniformly” distributed in time, these nodes were all stacked against the present (see picture).
> <beastS_hky_sampleprior_strictclock_rateupperlim_onepartition.annot.tree.png>
>
> This also occured when I set a strict clock model, and even with an upper limit to its rate. However when changing the “tree prior” to basic 'Yule' (default), Birth-Death or Coalescent, I get reasonable age distributions (see second picture).
> <beastS_hky_sampleprior_strictclock_rateupperlim_onepartition_BirthDeath.annot.tree.png>
>
> I ended up finding that the prior on the clock rate *and* the birth rate *have to* be specified, and be different from the uniform distribution. In fact the tutorial http://beast2-dev.github.io/beast-docs/beast2/DivergenceDating/DivergenceDatingTutorial.html does indicate it clearly.
>
> What puzzles me is, why is this only affecting the “Calibrated Yule Prior”, and not the other models like the Birth-Death?
>
> Wouldn't it be reasonable to emit an explicit warning in Beast about these improper priors?
>
> Thanks in advance,
>
> best,
>
> Guillaume
>
> --
> You received this message because you are subscribed to the Google Groups "beast-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beast-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/007614e6-f112-4fcd-a148-8030f39552e0n%40googlegroups.com.
> <beastS_hky_sampleprior_strictclock_rateupperlim_onepartition_BirthDeath.annot.tree.png><beastS_hky_sampleprior_strictclock_rateupperlim_onepartition.annot.tree.png>

Guillaume L

unread,
Feb 22, 2024, 12:06:23 PMFeb 22
to beast-users
Hi Alexei,

thanks a lot for the details!

I forgot to mention that I constrained the monophyly of 16 clades (out of 20 internal nodes), and that my two calibrations are applied to the root node, and to one of its direct children.

In this help page: https://beast2-dev.github.io/hmc/hmc/Priors/YuleBirthRatePrior/ it says “setting a prior on the root age can keep the birth rate in check, even with improper priors”. However, if I understood correctly, it does not apply to the Calibrated Yule?

One last question: if Yule is a special case of the Birth-Death, it should be equivalent to choosing the Birth-Death model while fixing the death rate to 0 ? But I guess that the implementation differ?

Best,

Guillaume

Alexei Drummond

unread,
Feb 22, 2024, 3:47:22 PMFeb 22
to beast-users
Hi Guillaume,

Regarding the advice on "https://beast2-dev.github.io/hmc/hmc/Priors/YuleBirthRatePrior/“. The advice generally looks good but I don’t agree with the advice regarding setting a root prior *instead of* of prior on birth rate. I think that this will go wrong in certain situations. This is my understanding:

"Calibrated Yule" prior + Normal root prior + improper birth rate prior -> Improper
"Calibrated Yule" prior + Log-normal root prior + improper birth rate prior -> Improper
Yule prior + Normal root prior + improper birth rate prior -> Improper

Yule prior + Log-normal root prior + improper birth rate prior -> Probably okay
Yule prior + Normal root prior + Normal birth rate prior -> Very probably okay
Yule prior + Normal root prior + log-normal birth rate prior -> Very probably okay

Yule prior + Log-normal root prior + Log-normal birth rate prior -> proper
"Calibrated Yule" prior + Log-normal root prior + Log-normal birth rate prior -> proper

Personally I would only use the last two settings. In general I would never use a normal prior for a scale parameter (i.e. a parameter that is strictly positive with no upper limit) like birth rate or a node age. You can always find a log-normal distribution that will represent your prior knowledge and will have support that goes smoothly to zero as the parameter approaches zero, which is an important property when parameters are interacting in they way they do in the tree prior.

Finally, Yule is indeed a special case of birth-death and should be equivalent to deathRate = 0 and samplingProportion = 1, with some small potential difference due to different treatment at the root in some conditionings of birth-death models.

Cheers
Alexei

Tim Z

unread,
Nov 26, 2024, 12:04:09 PM (13 days ago) Nov 26
to beast-users
Hello Alexei,

Thank you so much for this information! This is exactly the answer I have been trying to look for. I am relatively new to Bayesian phylogeny inference and would much appreciate any suggestions. Going on with the discussion thread...

1/ Could you explain a bit more why the Calibrated Yule Model would result in all taxa "shrinking" to the edge of the tree with very short branch lengths, even though we have given the tree node calibration information? I was relatively perplexed by this, since some online tutorials in taming the beast says "Calibrated Yule Model is good when you have calibration points"...

2/ I am working with mitochondrial genomes of invertebrates. I have chosen a few fossil records for calibration purposes and would like to perform node dating and divergence time estimation. In this situation, what tree prior models would you recommend I choose? For each of the model, there are many parameters and distribution associated with it. Without a very deep and intensive understanding of Bayesian statistics, how could I determine how I could adjust the parameters, or just leave them as default?

Thank you very much again!

Best,
Tim
Reply all
Reply to author
Forward
0 new messages