-
Notifications
You must be signed in to change notification settings - Fork 95
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
Significantly reduced DEL SUPPORT #484
Comments
Hi @hermannromanek , any thoughts/suggestions on this? |
Thanks @weishwu I suspect that there might be something else going on as Sniffles ignores some reads due to quality. Have you tried to just run with default parameters? Thanks |
Hi @weishwu Sorry for the late reply - as Fritz suggested, sharing a (regional) bam file could help us identifying whats going on here. With the next version of sniffles we included the fix for an issue with with very clean cut deletions, so this may already be fixed as well, but we'd have to double check it. Thanks, |
Hi @fritzsedlazeck |
Hi @weishwu I registered through my Github account on globus - can you please also share the directory with me? Thanks, |
I ran Sniffles2 to call SVs from my amplicon ONT data. In one of the samples there is a strong ~34bp deletion that is carried by more than half of the reads:
As shown on IGV, this deletion starts from position 188 and ends at 221. However in the Sniffles2 output, this deletion was called as:
Sniffles2 shifted the start position to 181 (and the DEL length became 40, which may be caused by some reads that have a longer DEL at this locus). What is more concerning, the SUPPORT is 89, hugely lower than the truth as shown on IGV.
I filtered out the alignments that had mapq<20 so it can't be because of that.
Below are all the SVs called by Sniffles2. No neighboring DEL can explain the loss of SUPPORT:
My command-line:
Any ideas? Thanks.
The text was updated successfully, but these errors were encountered: