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

v0.9.21-12-g92eb53a failing with -t option #163

Closed
jpuritz opened this issue Apr 14, 2015 · 7 comments
Closed

v0.9.21-12-g92eb53a failing with -t option #163

jpuritz opened this issue Apr 14, 2015 · 7 comments
Labels

Comments

@jpuritz
Copy link

jpuritz commented Apr 14, 2015

Hey Erik,

All of my FreeBayes runs are now failing after a few variants when using the -t option. Something changed between v0.9.21-12-g92eb53a and v0.9.20-4-g42d6a54

@jpuritz
Copy link
Author

jpuritz commented Apr 14, 2015

Any version of 0.9.21 fails.

@ekg
Copy link
Collaborator

ekg commented Apr 14, 2015

Is there a quick way I could reproduce this? I'm trying to add test cases,
but I already am testing --targets so I'll need another example to add.

On Tue, Apr 14, 2015 at 5:37 AM, jpuritz notifications@github.com wrote:

Any version of 0.9.21 fails.


Reply to this email directly or view it on GitHub
#163 (comment).

@jpuritz
Copy link
Author

jpuritz commented Apr 14, 2015

Erik,

Thanks for the quick reply. I've linked a test case with output and log files from runs with and without targets using the latest version and version 0.9.20.

Thanks!

https://www.dropbox.com/s/r4znronfga5zujr/testcase.tar.gz?dl=0

ekg added a commit that referenced this issue May 20, 2015
I've verified that freebayes now only works using whole-chromosome sequences.
The anti-pattern of trying to cache little bits of the reference has been
resolved by removing offending methods in the AlleleParser. The system should
also run much faster.

This likely affects #163, #166, #168, #170, but reporters need to test before I
close these.
@jpuritz
Copy link
Author

jpuritz commented May 21, 2015

Hey Erik,

I took a quick look at the fix and it seems to be working correctly. I'm getting slightly different results from the two different versions ( on a small test data set) in terms of genotypes and variant calls, but it is somewhere over 99% concordance. The discordance is highest, it seems, at sites that are INDEL or complex at the end of a reference contig. Not too surprising. I'll keep looking into this next week and will keep you informed.

Thanks,

Jon

@ekg
Copy link
Collaborator

ekg commented May 21, 2015

Hey Jonathan,

Thanks for the quick feedback. Note that you'll need to pull in the current
git head if you need --variant-input. The discordance at the end of the
contigs is concerning. If it looks like a regression let me know.

Erik
On May 21, 2015 8:20 AM, "jpuritz" notifications@github.com wrote:

Hey Erik,

I took a quick look at the fix and it seems to be working correctly. I'm
getting slightly different results from the two different versions ( on a
small test data set) in terms of genotypes and variant calls, but it is
somewhere over 99% concordance. The discordance is highest, it seems, at
sites that are INDEL or complex at the end of a reference contig. Not too
surprising. I'll keep looking into this next week and will keep you
informed.

Thanks,

Jon


Reply to this email directly or view it on GitHub
#163 (comment).

@github-actions
Copy link

This issue is marked stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the Stale label Dec 12, 2020
@github-actions
Copy link

This issue was closed for lack of activity. Feel free to re-open if someone feels like working on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants