Open weishwu opened 5 months ago
Hi @hermannromanek , any thoughts/suggestions on this?
Thanks @weishwu
is it possuble to share the bam file with us ?
Or maybe make a screenshot of the IGV? My email: fritz.sedlazeck@gmail.com
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 Fritz
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, Hermann
Hi @fritzsedlazeck I've shared a globus link with Fritz (fritz@access-ci.org). The folder contains the BAM, index, and the VCF. Let me know if you want me to use a different way to share the data. https://app.globus.org/file-manager?origin_id=af373541-899f-4eed-bae9-8ff738475f2d&origin_path=%2F @hermannromanek Sorry I can't find your account on globus. Thanks a lot for your help!
Hi @weishwu
I registered through my Github account on globus - can you please also share the directory with me?
Thanks, Hermann
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.