How to explain that mutations called by Mutect2 are inconsistent with what I saw in iGV?

Question

[Makplus T]

Hello,

I have ran the Mutect2 with tumor only mode and get the VCF file, and then I check the mutation site in iGV with a bamout file and my raw bam file from bwa, but I have trouble in explain why Mutect2 only report one position while there are about 4 site obvious . mycode:

gatk Mutect2 -R $ref -I tumor.bam \
    --germline-resouce af_genomAD.vcf.gz \
    -bamout bamout.bam \
    -O my.vcf.gz

I have follow the troubleshooting guide from GATK. Expected variant at a specific site was not called But it cannot explain this phenomenon well.

I want to know if anyone has the same problem, or there are some better explanations. This is the my raw bam file from bwa-mem. Thanks

[Kevin Blighe]

GATK (Mutect2) is known to miss obvious variants like this, even clinically-actionable variants. There is, as yet, no clear reason why. I first observed this back in 2013 / 4 while working in a Children's hospital in England, and noticed how Sanger-confirmed variants were not being called by GATK in live samples coming into the lab. I have written on this topic:

• A: Downsample BAM for targeted NGS panels
• Sanger sequencing is no longer the gold standard?
• A: Best tool for variant calling

You could possibly try the downsampling approach that I developed - see the first of my posts above. This should allow you to overcome this.

Kevin

[Makplus T]

Thanks for your helpful answer, I would try the approach your mentioned.

But I have some confuse on the reason why we need multi-bam for one sample with different downsample rate ? And why we need downsample in variants calling? In order to reduce something such as data volume, elapsed time, and RAM?

[Kevin Blighe]

But I have some confuse on the reason why we need multi-bam for one sample with different downsample rate ? And why we need downsample in variants calling?

The exact explanation is, as yet, unknown. Note that this issue does not occur with multi-pileup-based methods, like the one used by SAMtools / BCFtools.

Answer 1

[davidben]

Is this amplicon data? It certainly looks that way from the read starts and ends.

This has been a weakness for quite a while, but recent advances to our assembly engine usually help greatly. The new assembly is not yet turned on by default, so you will need a few extra arguments. Please see this discussion on the GATK forum: https://gatk.broadinstitute.org/hc/en-us/community/posts/360059696811-Mutect2-not-calling-a-4-bp-deletion-in-BRCA1-with-50-AF as well as this one https://gatkforums.broadinstitute.org/gatk/discussion/24507/mutect2-repeatedly-not-detecting-somatic-variant-idh2-r172k-with-solid-read-support-and-5-af on the old forum.

I recommend posting these kinds of questions on the GATK forum both because you may get a good answer and because that's how bugs get fixed. In fact, if the above forum threads don't resolve the issue, please post on the forum! I know I speak for the entire GATK team when I say that we want to know when our tools don't work correctly. Disclaimer, in case it wasn't already apparent: I'm the lead developer of Mutect2.

PS Apologies for being nosy. I don't spend my time lurking on BioStars, but a communication with a user led me to this thread.

[Kevin Blighe]

Thanks for posting, David. I should add, however, that a few users end up here because they don't receive assistance on the GATK forum. For issues like this user's, they appear to be told that the issue will be addressed at some future unknown point. Perhaps something to address internally at Broad Institute, which may necessitate policy change.

[davidben]

You are right about that. Our comms team is too small for the large volume of forum questions, which now includes not just GATK but also our entire ecosystem of cloud computing. They are hiring more people to handle the forum. Nonetheless, posting is still helpful, though we don't begrudge your seeking answers elsewhere.