Linearly increasing prior trace plot when using random local clock model

[­Wonseop Lim]

Hi, I was conducting fossil calibrated timetree construction using BEAST 2.7.6 utilizing random local clock model (tree and clock model linked, subs models unlinked). However, when I ran the MCMC chain I observed linearly increasing prior trace plot (screenshot shows only few ten-thousand generations but when I ran the analysis with approximately 1M generations, situation was almost the same). 

I'm pretty sure it has to do something with the identifiability issue between substitution and clock models, but I cannot clearly see what is causing the problem. I am appending the site and clock panel of BEAUti for the reference. Thanks in advance!

[Alexei Drummond]

Those two plots both appear to be for 71000 steps. You will need to run the MCMC chain for longer. It is still in burn-in.

On 24/06/2024, at 9:54 AM, ­Wonseop Lim <davi...@snu.ac.kr> wrote:

Hi, I was conducting fossil calibrated timetree construction using BEAST 2.7.6 utilizing random local clock model (tree and clock model linked, subs models unlinked). However, when I ran the MCMC chain I observed linearly increasing prior trace plot (screenshot shows only few ten-thousand generations but when I ran the analysis with approximately 1M generations, situation was almost the same). 

<d.PNG>

I'm pretty sure it has to do something with the identifiability issue between substitution and clock models, but I cannot clearly see what is causing the problem. I am appending the site and clock panel of BEAUti for the reference. Thanks in advance!

<e.PNG><f.PNG>

--
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/a9eb7c6f-e237-4419-aade-627d2fcb61d1n%40googlegroups.com.
<d.PNG><f.PNG><e.PNG>

[­Wonseop Lim]

Hi Alexei,

Although I only ran the analysis for about 1 million generations (screenshot I posted was just to give some impressions about the situations as I already terminated the original analysis,,, sorry for the confusion), prior distribution kept increasing infinitely. Also, when using nested sampling, xml file with equal settings gave positive marginal likelihood value, which I believe is unrealistic. What could possibly causing this results? I do not have any improper priors by the way.

2024년 6월 24일 월요일 오전 9시 14분 22초 UTC+9에 Alexei Drummond님이 작성:

[­Wonseop Lim]

I think I found a problem: clock rate priors were somehow duplicated multiple times (equal to number of partitions). Perhaps due to bug when constructing xml with BEAUti? 

After re-making the xml file now prior (&posterior) converges to reasonable value.

2024년 6월 24일 월요일 오전 8시 8분 24초 UTC+9에 ­Wonseop Lim님이 작성:

[­Wonseop Lim]

+, bunch of clock rates appear although I only have a single clock model:

However, when I manage to make (somehow) xml file with only one clock rate appearing in the priors panel, MCMC run does not behave like the way I mentioned in the first question (seems to converge rather quickly since the trace plot reaches logistic shape, not linear shape, within about 30,000 generations).

2024년 6월 24일 월요일 오전 9시 14분 22초 UTC+9에 Alexei Drummond님이 작성:

Those two plots both appear to be for 71000 steps. You will need to run the MCMC chain for longer. It is still in burn-in.

[­Wonseop Lim]

Turns out that although prior settles some stationary value but is still positive, and marginal likelihood obtained by nested sampling is also positive...

I am appending a link for the xml file I used for the test drive. Any help will he appreciated... Thanks in advance.

https://drive.google.com/file/d/1HXSfhx6sJeqd3y8qVoWV5-nBmKWk46lv/view?usp=sharing

2024년 6월 24일 월요일 오전 11시 33분 3초 UTC+9에 ­Wonseop Lim님이 작성:

[Artem B]

To get the only one clock rate prior you can try to select all partitions and then clicking 'link clock model'

Best,
Artem

вторник, 25 июня 2024 г. в 15:08:06 UTC+8, ­Wonseop Lim: