Mutect2 missing a low AF known deletion
Hi,
We have a patient who we are following with Illumina trusight myeloid amplicon panel every other month. In the previous 4 samples we all detected a 9 base deletion in TP53 at chr17:7577542 NM_000546.5:c.730_738delGGCGGCATG. But in the most recent sample we could not detect it using GATK 4.2.4.0 Mutect2 in tumor only mode. I followed suggestions in the forum thread When HaplotypeCaller and Mutect2 do not call an expected variant (https://gatk.broadinstitute.org/hc/en-us/articles/360043491652-When-HaplotypeCaller-and-Mutect2-do-not-call-an-expected-variant) and still cannot call the deletion. The 9 base deletion shows up in the base quality score re-calibrated bam using IGV, but not in any Mutect2 output bam files no matter how I use the combination choices of suggested parameter settings: --linked-de-bruijn-graph true --recover-all-dangling-branches true --min-pruning 0. In the Mutetc2 output bam files, the reads all start at chr17:7577547 and all reads before chr17:7577547 in base quality score re-calibrated bam are gone. The difference I can tell is that in previous samples the AF is between 0.33 to 0.52 and in this sample the raw AF judged from the base quality score re-calibrated bam is less then 0.03.
Here is the IGV:
The top is the base quality score re-calibrated bam, the middle is the Mutect2 output using my original setting --min-pruning 10, and the bottom is using --linked-de-bruijn-graph true --recover-all-dangling-branches true --min-pruning 0.
My Mutect2 command is:
java -Dsamjdk.use_async_io_read_samtools=false -Dsamjdk.use_async_io_write_samtools=true -Dsamjdk.use_async_io_write_tribble=false -Dsamjdk.compression_level=2 -Xms4g -Xmx30g -jar /opt/apps/gatk-4.2.4.0/gatk-package-4.2.4.0-local.jar Mutect2 --reference /data1/refGenome/gatk_hg19/ucsc.hg19.fasta --input BJtest.bqsr.bam --panel-of-normals /data1/refGenome/gatk_hg19/Mutect2-exome-panel_hg19.vcf --germline-resource /data1/refGenome/gatk_hg19/af-only-gnomad.raw.sites.hg19.vcf.gz --f1r2-tar-gz BJtest.f1r2.tar.gz --max-reads-per-alignment-start 0 --linked-de-bruijn-graph true --recover-all-dangling-branches true --min-pruning 0 --af-of-alleles-not-in-resource 0.0000025 --native-pair-hmm-threads 6 --disable-read-filter MateOnSameContigOrNoMappedMateReadFilter --intervals /data1/refGenome/panelBed/trusight-myeloid-amplicon-track.hg19.bed --interval-padding 100 --alleles /data1/refGenome/Seraseq_m2FA_sitesOnly.vcf --output BJtest_test.mutect2.vcf.gz --bam-output BJtest_test.mutect2.bam --create-output-bam-index true --independent-mates true --debug-assembly true
The log file and the subset bam files are on google drive https://drive.google.com/drive/folders/1S7xVBwaBQBAbvWfWEvlPzf67ZeiX-y9u?usp=sharing
Thanks a lot for the help!
Ying
-
Hi Ying,
Thank you for writing into the forum! I hope that we can help you figure this issue out.
The first thing I wanted to note is that the bamout will only show reads if there is an active region at that site. So, if there is nothing in the bamout, it means that there is no active region detected. Tumor-only calling is quite challenging in terms of getting high quality results, especially when looking for a variant with a low AF of 0.03. This could easily be deemed below the germline filtering threshold.
There's some follow up information I need in order to better understand what is happening at this site:
- Try force calling this site with the --alleles option in Mutect2 and please paste the VCF output.
- In your IGV screenshot, please highlight the site of interest and click on the site so that I can easily see the depth of each allele.
Best,
Genevieve
-
Hi Genevieve,
Thanks a lot for the suggestion. I ran the tests with the site chr17:7577542 added to the force calling site list and all test runs called the 9 base deletion with AF 0.025 no matter what options I set for --linked-de-bruijn-graph true / --recover-all-dangling-branches true / --min-pruning 0.
Here is the copy from one vcf:
chr17 7577542 . TCATGCCGCC T . . AS_SB_TABLE=10519,11258|256,292;DP=22325;ECNT=1;MBQ=20,20;MFRL=225,225;MMQ=60,60;MPOS=19;POPAF=5.60;TLOD=1346.38 GT:AD:AF:DP:F1R2:F2R1:FAD:SB 0/1:21777,548:0.025:22325:21604,542:0,0:21777,548:10519,11258,256,292
Here is the IGV screenshot:
The top is the original BQSRed bam, the second is original Mutect2 output bam. The bottom two are from two test runs with chr17:7577542 added to the force calling site list.
What's the best practice to handle such scenario? Every time we miss a known mutation, we just add the site to the force calling list?
Thanks a lot for the help!
Ying
-
Thanks Ying! This is very helpful. Does this site pass filtering with FilterMutectCalls when you force call the site?
-
Hi Genevieve,
Actually it passed the filtering which is a surprise to me.
chr17 7577542 . TCATGCCGCC T . PASS AS_FilterStatus=SITE;AS_SB_TABLE=10519,11258|256,292;DP=22325;ECNT=1;GERMQ=93;MBQ=20,20;MFRL=225,225;MMQ=60,60;MPOS=19;POPAF=5.6;ROQ=93;TLOD=1346.38;ANN=T|conservative_inframe_deletion|MODERATE|TP53|TP53|transcript|NM_000546.5|protein_coding|7/11|NM_000546.5:c.730_738delGGCGGCATG|NM_000546.5:p.G244_M246del|940/2591|730/1182|244/393||;GE_AC=.;GE_AF=.;GE_AN=.;GG_AC=.;GG_AF=.;GG_AN=.;CLNDISDB=MedGen:C0085390,Orphanet:ORPHA524,SNOMED_CT:428850001;CLNDISDBINCL=.;CLNDN=Li-Fraumeni_syndrome;CLNDNINCL=.;CLNHGVS=NC_000017.10:g.7577548_7577556del;CLNREVSTAT=criteria_provided,_single_submitter;CLNSIG=Uncertain_significance;CLNSIGCONF=.;CLNSIGINCL=.;CLNVC=Deletion;CLNVCSO=SO:0000159;CLNVI=.;GENEINFO=TP53:7157;CLINVAR GT:AD:AF:DP:F1R2:F2R1:FAD:SB 0/1:21777,548:0.025:22325:21604,542:0,0:21777,548:10519,11258,256,292
Thanks,
Ying
Please sign in to leave a comment.
4 comments