Mutect2 calls long deletion with absolutely zero read support
Answered
If you are seeing an error, please provide(REQUIRED) :
a) GATK version used: 4.2.1.0
b) Exact command used:
/gatk/gatk Mutect2 --java-options "-Xmx8g" -O $1 -R $2 -I $3 -tumor "$TUMOR" -I $4 -normal "$NORMAL" -L $5
c) Entire error log:
If not an error, choose a category for your question(REQUIRED):
c) Why do I see (......)?
I am seeing a long deletions variant being called between two sets of bam reads with REF,ALT depth of 140,2 respectively. However this is in a gap between two sets of reads where there is literally zero read support for the variant (see blue bar at top in image representing the deletion)
.
-
Hi Brian Wiley,
I would recommend taking a look at the bamout file generated with the option -bamout, as this will show the reads after local reassembly.
We also have an article going through why certain variants would be called. Take a look at the article and the troubleshooting recommendations, then let me know if you have follow up questions: https://gatk.broadinstitute.org/hc/en-us/articles/360043491652-When-HaplotypeCaller-and-Mutect2-do-not-call-an-expected-variant
Best,
Genevieve
-
Well, I got similar issue as Brian Wiley and I'd like to share more details:
The track above is original sorted bam, and below is the bam from mutect2. There are 9mer deletion at micro-satellite of "tgg"s, but mutect2 re-assembled these reads, mutect2 found a "more perfect alignment" at 40 bp upstream, then there's a 50bp deletion called.
-
Have you had a chance to look through the troubleshooting document When HaplotypeCaller and Mutect2 do not call an expected variant and see if any of those solutions are applicable? It's expected that some things will change after local realignment. Here's an article about Mutect2's local re-assembly and haplotype determination.
Please sign in to leave a comment.
3 comments