Random Local Clock fails to initialise by adding Newick starting tree

[anthonypmor]

Dear Beast Users and Developers

I am trying to run a Random Local clock Analysis, and providing a Newick starting tree.

If I run the analysis with a Random Starting tree, the chain initializes ok.

However, when I add a Newick starting tree, I get the Fatal exception: Could not find a proper state to initialise.error message, that attributes a infinite 

I don't understand why this happens, given that the prior specifications are the same if I add the the Newick or not, and the program appears to inform that the priors are the problem

P(Clade C.prior) = -Infinity (was -Infinity)

P(Clade D.prior) = NaN (was NaN)  **

P(GammaShapePrior.s:Suessiales_aligned) = -0.9147 (was -0.9147)

P(likelihood) = NaN (was NaN)  **

P(treeLikelihood.Suessiales_aligned) = NaN (was NaN)  **

Can anyone advise me how to proceed?

I can provide the xml if it helps

Thank you so mutch

Cheers

Anthony

[Remco Bouckaert]

Hi Anthony,

There are two ways the prior can be incompatible with a Newick starting tree:

1. the clade specified in the calibration is supposed to be monophyletic, but the starting tree has extra taxa for the clade. To fix this, the topology of the starting tree needs to be adjusted.

2. the age of the clade is not compatible with the calibration, for example, when the calibration requires the age to be at least X years old, but the starting tree has a younger age. If no branch lengths are specified in the starting tree, there is no way of telling what the age of the clade is, so you must specify branch lengths. If branch lengths are specified, ensure the Newick tree has an MRCA time that is inside the range of the calibration.

Cheers,

Remco

--
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/dbd2c4d6-4b2d-4860-ab25-266997021285%40googlegroups.com.

[anthonypmor]

Hi Remco,

Thank you for your reply.

Meanwhile I had figured out point no.2 could be the problem. Apparently I had both problems, so thanks for the insights, they were very helpfull.

Best regards

Anthony 

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

[anthonypmor]

Hi Remco,

I find that the tree topololgy isn´t kept while running either a Random Local Clock or a Relaxed Clock Lognormal, as oposed to running a Strict Clock.

Even when using a newick starting tree (created in MrBayes), the final topology changes after running relaxed clocks in Beast (although it improves with the imposed starting tree).

Why does this happen? Is their a way to make the analysis more constrained to the imposed starting tree? What would be the requisits for fixing the starting tree?

Thank you so mutch in advance

Best

Anthony  

segunda-feira, 6 de Janeiro de 2020 às 01:05:48 UTC, Remco Bouckaert escreveu:

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

[Remco Bouckaert]

Hi Anthony,

To keep the tree topology fixed, a number of tree changing operators need to be removed — see https://www.beast2.org/fix-starting-tree/ under "Fix the tree throughout BEAST run” for details how to do that and which operators to remove.

Hope this helps,

Remco

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/a3d6ccb5-2234-424b-bbc6-df9edff20fca%40googlegroups.com.

[anthonypmor]

Hi Remco,

After the Random Local Clock analysis, I'm getting poor  ESS for just the following parameters in Tracer:

posterior	-5575.695	83	R
likelihood	-5854.628	142	R
prior	278.933	81	R
treeLikelihood.	-5854.628	142	R

And I get the output from Beast as outilned below.

Do you think it is possible to tune some of the parameters to obtain higher ESS?

Thanks again

Operator                                                                           Tuning    #accept    #reject      Pr(m)  Pr(acc|m)

ScaleOperator(YuleBirthRateScaler.t:Symbiodiniaceae_aligned)                      0.49958     664238    2003923    0.02667    0.24895

ScaleOperator(YuleModelTreeScaler.t:Symbiodiniaceae_aligned)                      0.77368     478599    2187568    0.02667    0.17951

ScaleOperator(YuleModelTreeRootScaler.t:Symbiodiniaceae_aligned)                  0.63156     391479    2273897    0.02667    0.14688

Uniform(YuleModelUniformOperator.t:Symbiodiniaceae_aligned)                             -   11185066   15481849    0.26667    0.41944

SubtreeSlide(YuleModelSubtreeSlide.t:Symbiodiniaceae_aligned)                     8.15590    2388272   10945428    0.13333    0.17912

Exchange(YuleModelNarrow.t:Symbiodiniaceae_aligned)                                     -    3873857    9455422    0.13333    0.29063

Exchange(YuleModelWide.t:Symbiodiniaceae_aligned)                                       -      10037    2655721    0.02667    0.00377

WilsonBalding(YuleModelWilsonBalding.t:Symbiodiniaceae_aligned)                         -      11638    2656441    0.02667    0.00436

BitFlipOperator(IndicatorsBitFlip.c:Symbiodiniaceae_aligned)                            -     121968   13212535    0.13333    0.00915

ScaleOperator(ClockRateScaler.c:Symbiodiniaceae_aligned)                          0.14930    3458498    9875515    0.13333    0.25937

ScaleOperator(randomClockScaler.c:Symbiodiniaceae_aligned)                        0.67612     198049     690966    0.00889    0.22277

UpDownOperator(randomClockUpDownOperator.c:Symbiodiniaceae_aligned)               0.76729     635986    2031709    0.02667    0.23840

BMTMergeSplitOperator(BMT_ModelTestOperator.s:Symbiodiniaceae_aligned)                  -      78658     810193    0.00889    0.08849

BMTExchangeOperator(BMT_Ratescaler.s:Symbiodiniaceae_aligned)                     0.34707     190174     699617    0.00889    0.21373

BMTScaleOperator(BMT_gammaShapeScaler.s:Symbiodiniaceae_aligned)                  0.50281      97199     345935    0.00444    0.21934

BMTScaleOperator(BMT_ProportionInvariableScaler.s:Symbiodiniaceae_aligned)        0.44607     105017     339752    0.00444    0.23612

BMTBirthDeathOperator(BMT_hasGammaRatesFlipper.s:Symbiodiniaceae_aligned)               -          0      89231    0.00089    0.00000

BMTBirthDeathOperator(BMT_hasInvariableSitesFlipper.s:Symbiodiniaceae_aligned)          -       1660      87865    0.00089    0.01854

BitFlipOperator(BMT_FreqsFlipOperator.s:Symbiodiniaceae_aligned)                        -          4      88988    0.00089    0.00004

DeltaExchangeOperator(BMT_FrequenciesExchanger.s:Symbiodiniaceae_aligned)         0.06063      41936     135111    0.00178    0.23686

To view this discussion on the web visit https://groups.google.com/d/msgid/beast-users/a3d6ccb5-2234-424b-bbc6-df9edff20fca%40googlegroups.com.

[Remco Bouckaert]

Hi Anthony,


There are no hints on how to improve operator parameter settings, and accep=
tance rates look OK, so I don't think that will help a lot in this case. Ru=
nning longer (resuming from the end state) might fix the problem and would =
be the first thing to try.


I noticed that there are operators that change the tree topology (like the =
sub-tree slide, and exchange operators) -- previously you indicated being i=
nterested in keeping the topology fixed. Removing these operators (or setti=
ng their weights to 0) may also help in convergence (but might reduce uncer=
tainty, so you want to be sure of the topology).


Cheers,


Remco

[anthonypmor]

Hi Remco

Thank you for your reply.

I will try resuming from the end state as you suggested. Any tips on a tutorial to follow to do so? (i will try and find it anyway)

I am running 100 million chain length, logging every 1000 steps. I thought it would be sufficient (the data converge well under a strict clock), however my trace on the posterior and prior look weird (sent in attach).

Yes, I did try to fix the topology, but the ESS did not improve that much (although the output topology now made sense). The screenshot I sent was a different trial I made with fewer sequences to check whether "outgroup" sequences would be affecting the MCMC chain (which turned out not to be the case).

Now I was trying to define taxon sets, in hope that it would improve the way that the model could fit the data with a RLC. 

Would you be available to check my xml file and give some advice? I am struggling a bit in "transitioning" to relaxed clocks, from a consistent strict clock analysis, and I think there must be a simple answer to my problem, that may require an expert's eye.

 

Thank you so mutch

Best regards

Anthony

[Remco Bouckaert]

Hi Anthony,

Have you tried running an uncorrelated relaxed clock analysis? The random local clock is known to have trouble mixing some times where a relaxed clock can mix well. To switch between strict and relaxed clocks, just load the file in BEAUti and change clock models in the "clock model" panel.

The plot you posted shows that prior and posterior mix badly, but it is not clear which part of the prior mixes badly. On the other hand, it does not look that unregular that just running it longer will probably give you better ESSs. Make sure to run multiple chains and check whether they all converge to the same distribution though.

To resume, see: https://www.beast2.org/2014/04/07/checkpointing-tricks.html

Cheers,

Remco

--
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/0ec97d3d-f8a3-4e85-b7ba-7e8e923871b0%40googlegroups.com.
<Tracer.png>

[anthonypmor]

Hi Remco,

Thank you again for your insightful help.

Yes, I have tried the uncorrelated relaxed clock lognormal, and indeed the trace file look better and the ESS values increase approximately two-fold, despite not always >200. I will try running both analyses longer this time. I meant to preferably use the RLC because of the ability to test whether my data are described by a global clock or not.

Anyway I will try your suggestions.

Thanks again

Cheers

Anthony

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