WARNING: no up item specified in UpDownOperator

[Diego Caraballo]

Hi everybody! I am having trouble running *BEAST. The following message is printed in the text buffer when I attempt to run an analysis. I don't perceive intuitively what the UpDownOperator does, and what's the nature of the error message. I can attach the complete .xml file if necessary.

Hope you can help me!

Cheers,

Diego

File: GHR_Cyt-b.xml seed: 1454702966454 threads: 1

  Using BEAGLE version: 2.1 resource 0: CPU

    with instance flags:  PRECISION_DOUBLE COMPUTATION_SYNCH EIGEN_REAL SCALING_MANUAL SCALERS_RAW VECTOR_SSE THREADING_NONE PROCESSOR_CPU FRAMEWORK_CPU

  Using BEAGLE version: 2.1 resource 0: CPU

    with instance flags:  PRECISION_DOUBLE COMPUTATION_SYNCH EIGEN_REAL SCALING_MANUAL SCALERS_RAW VECTOR_SSE THREADING_NONE PROCESSOR_CPU FRAMEWORK_CPU

  Using BEAGLE version: 2.1 resource 0: CPU

    with instance flags:  PRECISION_DOUBLE COMPUTATION_SYNCH EIGEN_REAL SCALING_MANUAL SCALERS_RAW VECTOR_SSE THREADING_NONE PROCESSOR_CPU FRAMEWORK_CPU

  Ignoring ambiguities in tree likelihood.

  With 275 unique site patterns.

  Using rescaling scheme : dynamic

  Ignoring ambiguities in tree likelihood.

  With 371 unique site patterns.

  Using rescaling scheme : dynamic

  Ignoring ambiguities in tree likelihood.

  With 133 unique site patterns.

  Using rescaling scheme : dynamic

  Using BEAGLE version: 2.1 resource 0: CPU

    with instance flags:  PRECISION_DOUBLE COMPUTATION_SYNCH EIGEN_REAL SCALING_MANUAL SCALERS_RAW VECTOR_SSE THREADING_NONE PROCESSOR_CPU FRAMEWORK_CPU

  Ignoring ambiguities in tree likelihood.

  With 72 unique site patterns.

  Using rescaling scheme : dynamic

WARNING: no up item specified in UpDownOperator

Start likelihood: -Infinity after 10 initialisation attempts

P(posterior) = -Infinity (was NaN)

P(speciescoalescent) = 764.5976031315347 (was NaN)

P(SpeciesTreePopSize.Species) = 540.7221801150212 (was NaN)

P(treePrior.t:Cyt-b_Tree) = 15.393779274439881 (was NaN)

P(treePrior.t:GHR_Tree) = 208.48164374207366 (was NaN)

P(prior) = -Infinity (was NaN)

P(BirthDeath.t:Species) = 128.85791705907997 (was NaN)

P(BirthRatePrior.t:Species) = -6.907755278982137 (was NaN)

P(GammaShapePrior.s:Cyt-b_1st2nd) = -0.49510000000000004 (was NaN)

P(GammaShapePrior.s:Cyt-b_3rd) = -2.874247180559945 (was NaN)

P(GammaShapePrior.s:GHR_3rd) = -1.2297471805599454 (was NaN)

P(KappaPrior.s:Cyt-b_1st2nd) = -2.5446928104028164 (was NaN)

P(KappaPrior.s:GHR_1st2nd) = -2.0468027065236347 (was NaN)

P(KappaPrior.s:GHR_3rd) = -1.8296853377683084 (was NaN)

P(popMean.prior) = 5.823855061160588 (was NaN)

P(PropInvariantPrior.s:Cyt-b_1st2nd) = 0.0 (was NaN)

P(PropInvariantPrior.s:Cyt-b_3rd) = 0.0 (was NaN)

P(PropInvariantPrior.s:GHR_1st2nd) = 0.0 (was NaN)

P(RateACPrior.s:Cyt-b_3rd) = -3.184008455701433 (was NaN)

P(RateAGPrior.s:Cyt-b_3rd) = -14.008535452892017 (was NaN)

P(RateATPrior.s:Cyt-b_3rd) = -3.184008455701433 (was NaN)

P(RateCGPrior.s:Cyt-b_3rd) = -3.184008455701433 (was NaN)

P(RateGTPrior.s:Cyt-b_3rd) = -3.184008455701433 (was NaN)

P(DeathRatePrior.t:Species) = 0.0 (was NaN)

P(MeanRatePrior.c:Cyt-b_Clock) = -2.3045850929940457 (was NaN)

P(MeanRatePrior.c:GHR_Clock) = -2.402585092994046 (was NaN)

P(Group1.prior) = -Infinity (was NaN)

P(Group2.prior) = NaN (was NaN)

P(Group3.prior) = NaN (was NaN)

P(Group4.prior) = NaN (was NaN)

P(Group5.prior) = NaN (was NaN)

P(Root.prior) = NaN (was NaN)

P(likelihood) = NaN (was NaN)

P(treeLikelihood.Cyt-b_1st2nd) = NaN (was NaN)

P(treeLikelihood.Cyt-b_3rd) = NaN (was NaN)

P(treeLikelihood.GHR_1st2nd) = NaN (was NaN)

P(treeLikelihood.GHR_3rd) = NaN (was NaN)

java.lang.Exception: Could not find a proper state to initialise. Perhaps try another seed.

at beast.core.MCMC.run(Unknown Source)

at beast.app.BeastMCMC.run(Unknown Source)

at beast.app.beastapp.BeastMain.<init>(Unknown Source)

at beast.app.beastapp.BeastMain.main(Unknown Source)

at beast.app.beastapp.BeastLauncher.main(Unknown Source)

[Diego Caraballo]

I think I know where the problem is, but have no idea to fix it.

I find in my .xml file the following operator:

    <operator id="updown.all.Species" spec="UpDownOperator" scaleFactor="0.75" weight="3.320396972737047">

        <down idref="popMean"/>

        <down idref="popSize"/>

        <down idref="Tree.t:Species"/>

        <down idref="Tree.t:Cyt-b_Tree"/>

        <down idref="Tree.t:GHR_Tree"/>

        <down idref="popSizeTop"/>

    </operator>

I guess here is where the upper item is missing. Is it?

I attach the xml with the hope the error source can be identified.

Cheers,

Diego

[Remco Bouckaert]

Hi Diego,

The problem is that there are calibrations specified, but a birth-death tree prior was selected. This combination is known to result in a tree prior that is biased (unlike the “Calibrated Yule”, which can deal with such bias).

The starting trees generated by the StarBeastStartState are not compatible with the calibrations you specified (it should at least warn that this is the case, so I raised an issue on this #503). Unfortunately, the calibrated Yule is very slow when here are more than a handful of calibrations, so for this analysis the birth-death may be more practical.

I edited the XML to use different tree initialisers such that it starts now, but you want to check that the tree prior is behaving the way you think it should.

Cheers,

Remco

PS The up/down operator works even without up entry, but it does produce a warning to indicate something may be missing. You can add  <up idref="birthRate2.t:Species”/> to get better mixing and get rid of the warning.

[Diego Caraballo]

Remco,

Thank you so much for your help! It's immensely comforting to have the program running an analysis with these data! I have some questions both from your reply and by comparing my XML file with the one you modified.

When you say that a birth-death tree prior and node calibrations result in a biased tree prior, what's the nature of that bias? Should I consider using an alternative (and better) tree prior model? The reason why I chose birth-death over Calibrated Yule was because it is a more realistic model, since it takes into account extinctions not only branching processes.

 

What would be a reasonable way to test if the tree prior behaves as I think it should?

 

Looking at the XML I see that you've modified parameters affecting Population size. You've specified dimensions for PopSize and PopSizeTop. If it's not only a technical aspect, I would appreciate if you could explain to me the reasons for adding these items.

I understand that population size in tree prior model changed from linear with constant root, to constant.  If this is the case, should I expect divergence times to change?

FInally, in the Death Rate Prior the distribution changed from "Uniform.01" to "Uniform.011". Is it a typing error, or is it a different distirbution range?

 

I took also the suggestion of adding the line <up idref="birthRate2.t:Species”/> to the up/down operator. Should I also add a line concerning the relative death parameter ("relativeDeathRate2.t:Species")?

 

Thanks again for your invaluable help and advice.

Cheers,

Diego

[Remco Bouckaert]

Hi Diego,

The tree prior and calibration interact with each other, which means that the marginal distribution of the clade can be quite different from the calibration that you specify. So, if you specify say a normal distribution with mean M and sigma S, and you sample from the prior, you will see that the distribution for MRCA time of the clade may differ quite a lot from the calibration that you specified. See https://sysbio.oxfordjournals.org/content/61/1/138.full for examples. and more details.

I did not edit the population size parameters or the ID of the uniform distribution in the XML file you posted — perhaps you are comparing with another file? By the way, the id-attribute is just the identifier of the distribution, which has no impact on the model so you can change it to whatever name you like. However, any references to the element should be updated as well. Since distributions on calibrations are typically not referred from elsewhere in the model, it is harmless changing the id.

Cheers,

Remco

[Diego Caraballo]

Hi Remco,

Thanks again for your reply. Taking into account the paper you linked and your comments I understand that in order to analyze the possible interaction between the tree prior and calibration priors, I should run an analysis from the prior to check if the marginal distribution of each calibrated node matches with the calibration densities. If it isn't the case, how can I overcome this issue?

Cheers,

Diego

PS. Regarding population size parameters, I'd compared different versions of the file. 

[Remco Bouckaert]

Hi Diego,

If it turns out the marginal distributions are diverting too much, you can change the parameters of the calibration distribution and check that the updated prior matches your expectations. 

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 post to this group, send email to beast...@googlegroups.com.
Visit this group at https://groups.google.com/group/beast-users.
For more options, visit https://groups.google.com/d/optout.

[Pedro Paulo Goulart Taucce]

Dear all,

I am having the same problem, but I am using *BEAST2 with a Yule prior and I don't think I specified any calibration (although I specified a clock rate). I am posting my xml file without the sequences because I am using 388 loci and it would be bigger than google let me attach. If someone finds it important I will upload the entire xml somewhere. Does anyone know what I should do? Is it possible that the error is not letting the likelihood and posterior parameters to converge?

Thanks in advance!

[Huw A. Ogilvie]

Hi Pedro, can you post the console output you get from BEAST, with all the error messages?

[Pedro Paulo Goulart Taucce]

Hi,

Here is attached the whole run. 

Thanks!

Me. Pedro P. G. Taucce

Universidade Estadual Paulista "Júlio de Mesquita Filho" - UNESP

Instituto de Biociências

Departamento de Zoologia, Jacarezário

Av. 24 A, 1515, Bairro Bela Vista

Rio Claro - SP

CEP 13506-900

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

[Huw A. Ogilvie]

Hi Pedro,

If the clock rate of any locus is fixed, you'll get that "WARNING: no up item specified in UpDownOperator" message. Because the rates of all your loci are fixed at 7.76E-4, you're getting that message for all loci. As long as you intended to fix all the clock rates, it's actually working as intended :-)

- Huw

[Pedro Paulo Goulart Taucce]

Thank you very much for your answer!

Me. Pedro P. G. Taucce

Universidade Estadual Paulista "Júlio de Mesquita Filho" - UNESP

Instituto de Biociências

Departamento de Zoologia, Jacarezário

Av. 24 A, 1515, Bairro Bela Vista

Rio Claro - SP

CEP 13506-900

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