-
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
Large DEL filtered by Sniffles #367
Comments
Hi,
was filtered by Sniffles with I then tried to use Bests |
I had a similar issue...for a 160kb DEL validated orthogonally (Illumina, PCR) and clearly visible in the reads...but I do see that the coverage fluctuates near the centre of the deletion. Trying with --no-qc to see if the variant is removed, but would also +1 to Stefan's request for other parameters to alter for this specific problem. Thanks, |
Turns out for my DEL this is fully missed by Sniffles, but picked up by CuteSV. Even after adding the --no-qc as suggested above: Code:
(I know that in this snapshot I didn't expand feature visibility for the default sniffles but it's not there either). It's also not shown in the --no-qc file at all, showing this in the output VCF showing these variants upstream and downstream of our de novo deletion of interest:
From CuteSV (cutting out ref+alt cols because CuteSV puts the entire 164kb seq in the ref column...)
@fritzsedlazeck if there is a test version of Sniffles you'd like me to try to get this variant to be detected let me know. Thanks, |
Dear all, We have identified some things over the past weeks and will soon make a new release. @smolkmo is also further including other debug options (e.g. read tracing) so we can easier see why Sniffles is ignoring certain reads/regions easier. Thank you all |
Hello, ##fileformat=VCFv4.2 Best wishes to you. |
Hello,
I am using Sniffles Version 2.0.7.
We used nanopore sequencing with 18X median coverage to recover an 8Mb deletion.
Variant calling with Sniffles did not call this deletion, with default parameters and with
--long-del-coverage 1
But running Sniffles with the
--no-qc
option as suggested in #366 showed that this deletion was filtered because ofCOV_CHANGE
:Indeed, as I understand the
COV_CHANGE
filter, (14+15)/2*1 is still bigger than coverage near the center for this deletion (I assumed thesvcall.coverage_center
used forCOV_CHANGE
filtering is coverage near the center - so 16 here).In the future, I guess we could set a very high value for
--long-del-coverage
to not miss this kind of deletion.However, I feel like large coverage variation could be expected for such large deletion. Maybe, using the mean coverage for large deletion would be more appropriate ? Here, the mean coverage would be 11, so just under the threshold in our case with
--long-del-coverage
=1 .Also,
STDEV_LEN
andSTDEV_POS
=0, which could be considered for variant filtering.Thank you,
The text was updated successfully, but these errors were encountered: