BEAST2 giving me divergence times that are much too low

[Wilson Guillory]

Hi,

I am attempting to run a BEAST2 divergence time analysis on a fixed topology. I have one calibration prior, which is the node separating the outgroup and the ingroup. I set this prior to a normal distribution with a mean of 8.262 Ma and a standard deviation of 1.882 Ma, and an offset of zero (what I want is to tell BEAST that the ingroup diverged from the outgroup 8.262±1.882 Ma). However, after running my analysis for 500M generations BEAST estimated this divergence time at ~0.06 Ma, which is obviously much too low. 

What confuses me is that I initially ran the same analysis, with the same parameters, but for only 1M generations (essentially a test run), and obtained much more reasonable divergence time values (though all parameters had garbage ESS values due to the short number of generations). Perhaps, due to the infinite range of the normal distribution, the divergence time drifted very far towards zero over the course of the extra 499M generations in my second run?

I'm new to BEAST and Bayesian inference in general, so I have little idea what the issue is here. I'm running this on a single-partition alignment of 100 UCE loci for 63 taxa. I hope that someone who is familiar with this issue can provide me with some advice. 

[HS]

Hi,

I have a similar problem. The same analysis I did with small number of taxa and get proper results. But then, when I added more taxa, the analysis now behaves like you describe.

Did you find any solution? 

Could anyone else give some idea what to look for? Could there be some big data problem? I have 135 taxa, 124990 sites and  5152 patterns.

Best,

Hovhannes

[Alexei Drummond]

This will only happen when you use normal priors (i.e. priors that don’t go to zero at zero). If you use an equivalent lognormal prior then you will not have this problem.

Alexei

-- 
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 post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/e9193918-108e-4fc3-aa89-36098d8d2abb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[HS]

Dear Alexei,

Thank you very much for your response!

I tried to run the analysis with lognormal prior. Unfortunately, that doesn't solve the problem (my normal prior was well above 0 (M-19500, Sd-1950). By the way, these normal priors work better with Beast1. I mean the posterior distribution of the calibration node age remains the same as the prior distribution, but in this case the ESS values for population sizes are very low in BS analysis.

It is strange that the analysis with BEAST2 runs with different speeds - in the beginning it is slow, then it goes faster, then again slow, then again faster (25-30%).

I thought that this issue could be connected with the initial population sizes, and I've tried also the suggestion given by Remco in a different post - https://groups.google.com/d/msg/beast-users/0D1kwrnvtrs/t9wblTz5AQAJ that is to change the spec RandomTree with SimpleRandomTree, but this does not solve the problem as well.

Could there be some issue with big number of short branches in a narrow evolutionary period? 

Best,

Hovhannes

I tried 

On Monday, 13 May 2019 11:20:00 UTC+3, Alexei Drummond wrote:

This will only happen when you use normal priors (i.e. priors that don’t go to zero at zero). If you use an equivalent lognormal prior then you will not have this problem.

Alexei

On 13/05/2019, at 6:00 PM, HS <hovo...@gmail.com> wrote:

Hi,

I have a similar problem. The same analysis I did with small number of taxa and get proper results. But then, when I added more taxa, the analysis now behaves like you describe.

Did you find any solution? 

Could anyone else give some idea what to look for? Could there be some big data problem? I have 135 taxa, 124990 sites and  5152 patterns.

Best,

Hovhannes

On Tuesday, 19 June 2018 21:25:11 UTC+3, Wilson Guillory wrote:

Hi,

I am attempting to run a BEAST2 divergence time analysis on a fixed topology. I have one calibration prior, which is the node separating the outgroup and the ingroup. I set this prior to a normal distribution with a mean of 8.262 Ma and a standard deviation of 1.882 Ma, and an offset of zero (what I want is to tell BEAST that the ingroup diverged from the outgroup 8.262±1.882 Ma). However, after running my analysis for 500M generations BEAST estimated this divergence time at ~0.06 Ma, which is obviously much too low. 

What confuses me is that I initially ran the same analysis, with the same parameters, but for only 1M generations (essentially a test run), and obtained much more reasonable divergence time values (though all parameters had garbage ESS values due to the short number of generations). Perhaps, due to the infinite range of the normal distribution, the divergence time drifted very far towards zero over the course of the extra 499M generations in my second run?

I'm new to BEAST and Bayesian inference in general, so I have little idea what the issue is here. I'm running this on a single-partition alignment of 100 UCE loci for 63 taxa. I hope that someone who is familiar with this issue can provide me with some advice. 

-- 
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...@googlegroups.com.

[Alexei Drummond]

Hey Hovhannes,

What exactly does “This doesn’t solve my problem” mean? Which log-normal distribution did you use and what was the precise result? What exactly was the problem in the first place, quantitatively?

In theory, it doesn’t matter how far away from zero you are, a normal distribution supports the entire number line including negative numbers and that can cause problems depending on what your tree prior is. I would not recommend using a normal distribution for the calibration of a scale parameter (which an age is). I always use a log-normal distribution.

Cheers

Alexei

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

To post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/41b96b19-1346-4eaa-988f-3023cb175d74%40googlegroups.com.

[HS]

Dear Alexei,

I do Bayesian Skyline Analysis with Y chromosomal sequences. I force monophyly with haplogroup J1 sequences giving an age prior. I was doing it as a normally distributed prior with Mean=19500 and Sd=1950. With your suggestion I changed it and gave a lognormal prior with Mean in real space = 19500 and Sd=0.1. For the strict clock rate I provide lognormal prior with Mean 5.0E-8 (to be estimated) and S=2.0 (to be estimated). Popsize and groupsize dimensions I left to be 5.

The problem is that after the analysis the posterior distribution of J1 clade becomes lower - centered around 16000. ESS value is lower than 200, it is not converged. The topology of the tree remains - J1 clade remains as a monophyletic clade. So it does not matter which kind of prior you provide - normal or lognormal. The results are always the same - lower age with unconverged trace. 

Of course the age of J1 can be lower. i don't say that 19500 is the true age of this haplogroup. But I try to figure out what could be the basis, the source for the analysis to result in this estimate.

Cheers,

Hovhannes

To unsubscribe from this group and stop receiving emails from it, send an email to beast...@googlegroups.com.

To post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.

[Alexei Drummond]

Hi Hovhannes,

So if I understand correctly, you have a hierarchical prior on the clock rate? You have a lognormal prior on the clock rate whose M and S you also estimate as random variables? What priors do you put on M and S? If you have an informative prior on the clock rate that could definitely change the age of your calibrated node.

Very important: check the upper limit on the population sizes of the bayesian skyline model. We recently discovered that the template has a default upper limit of 380,000 (?!) which should not have been there. If you leave the prior as default then that could definitely cause problems for old trees in units of years. You should remove this upper limit or increase it as appropriate. 

The next release will not have this upper limit specified, and we eventually plan to require all those priors to be chosen explicitly by the user, so defaults like that don’t get used by mistake.

Cheers

Alexei

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

To post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/36162419-cac2-4524-a290-9a5a4c9858cc%40googlegroups.com.

[HS]

Hi Alexei,

I am not sure I understand the meaning of a "hierarchical prior" completely. Does it refer to an internal node's age prior? If yes, then yes I do it. 

In the ClockRate pane in the Priors tab I select lognormal and put flags for M and S. And I set M=5.0E-8 (in real space), S=2.

I noticed the upper prior's lower value and I increased it to 1.0E20. I think it is pretty enough. I can increase it if you think it is worth to try with a higher value.

I attach tracer figures for the age and posterior. There is a convergence problem - ESS values are around 20. 

Best wishes,

Hovhannes

To unsubscribe from this group and stop receiving emails from it, send an email to beast...@googlegroups.com.

To post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.

[Alexei Drummond]

Hi Hovhannes,

You can email me an XML if you want me to look at it.

I think it is standard to *not* estimate M and S, but instead treat them as fixed numbers that represent the prior on the clock rate. If you also estimate the M and the S then it becomes a hierarchical prior, in which you are estimating both the clock rate and the parameters of the prior on the clock rate.

But regardless, if you have any type of informative prior on the clock rate then you shouldn’t expect you calibrated node to necessarily retain its prior distribution, since there will be calibration information coming from both the node calibration and the rate calibration and they will have to find a compromise if they are not consistent with each other.

Alexei

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

To post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/138c0ff9-887f-4f0f-af47-80e5ead5d0a6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<J_age_trace.jpg><J_posterior_trace.jpg>

[HS]

Hi Alexei,

I will send you the xml later.

I just wanted to mention that it does not matter whether I estimate the Clock Rate or not. The results does not differ.

Also I know that it is not suggested to estimate both Mutation Rate and Clock Rate. So I don't estimate Mutation Rate, but only the Clock Rate. And as I already told, some times also neither of them.

Best,

Hovhannes