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

Feature request: Trust the wild type call when resolving overlap read mismatches #45

Open
hezscha opened this issue Feb 16, 2021 · 2 comments

Comments

@hezscha
Copy link

hezscha commented Feb 16, 2021

Hi,
concerning mismatch resolution between overlap read pairs, my lab was wondering if it's possible to implement resolving them by assuming that the base that matches the wild type is true in addition to using the base call qualities?
We have a site saturation mutagenesis library that should be mostly single amino acid variants, so there is strong support that wild type is the correct call if the disagreeing bases from forward and reverse both have the same quality.

@hezscha hezscha changed the title Feature report: Trust the wild type call when resolving overlap read mismatches Feature request: Trust the wild type call when resolving overlap read mismatches Feb 16, 2021
@afrubin
Copy link
Member

afrubin commented Feb 17, 2021

This is a good suggestion. I had originally planned to drop the overlapping paired end read mode in future projects, instead suggesting that users use FLASH2 or a similar program to calculate read overlaps, but this wild-type awareness could be a compelling reason to keep it around.

@ijhoskins
Copy link

ijhoskins commented Dec 9, 2021

@afrubin any thoughts on how Enrich2 will handle this moving forward?

I second @hezscha 's suggestion. I currently get a very high proportion of variant calls to "X" (~86%) with non-mutagenized (negative control) alignments. I see no reason not to resolve the variant if the base qualities are the same, especially if they are high. Unfortunately such high proportion of "X" calls makes the Overlap mode not useful for my case. Seems like the easiest work-around is to run in Basic mode with either R1 only or after merging pairs with PEAR, FLASH2, etc.

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

No branches or pull requests

3 participants