Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Likelihood incorrectly calculated error #1148

Open
jkimsis opened this issue Apr 19, 2024 · 5 comments
Open

Likelihood incorrectly calculated error #1148

jkimsis opened this issue Apr 19, 2024 · 5 comments

Comments

@jkimsis
Copy link

jkimsis commented Apr 19, 2024

Hello,

I'm encountering this error for some files with Beast v2.7.6. I found that there had been a similar issue in Beast 2.0.2: https://groups.google.com/g/beast-users/c/xrvcxeU4wwA

At sample 81010000
Likelihood incorrectly calculated: -4005.621548446859 != -4019.4435423486443(13.82199390178539) Operator: kernel.BactrianNodeOperator(CoalescentConstantUniformOperator.t:file1)
Too many corrections. There is something seriously wrong that cannot be corrected

I've tried using it with and without beagle, same result.

@rbouckaert
Copy link
Member

@jkimsis It is quite hard to say what is going on without further information. Do you have some XML available I can have a look at so I can investigate the problem?

@jkimsis
Copy link
Author

jkimsis commented Apr 21, 2024

I've attached xmls and log output for two runs that failed like this (C and I), and one that ran all the way through (NO). I ran several processes in parallel, could that be a problem?

parallel "~/install/beast/bin/beast -working -overwrite {}/{}.xml &> {}/{}.runlog" :::: names

I understand that beast has it's own multithreading, but the server I'm working with has some issue with it.
files.zip

@rbouckaert
Copy link
Member

Thanks, that is very helpful. I can reproduce the problem with these files without using threads, so I don't think that using the parallel processing is the problem. Will look further into what is causing this.

@rbouckaert
Copy link
Member

It looks like the problem is caused by numerical instability due to the clock rate exploding to a value very close to the maximum value that can be represented by a double value (around 1e304), which is unrealistically high.

Currently, for I.xml there are improper priors on the clock rate and pop sizes. Putting a much narrower prior on the clock rate, for example uniform(0, 1e-5) and an upper bound of say 100 on the popsize will fix the problem. There does not seem to be much signal in the sequences, so it will be necessary to keep these parameters in check in order for the analysis to succeed. Note that these values are just suggestions, but you have to make sure they are reasonable based on where the data came from.

@jkimsis
Copy link
Author

jkimsis commented Apr 22, 2024

Thank you, I'll experiment with that.

rbouckaert added a commit to CompEvol/beast2-site that referenced this issue Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants