Mutect2 --pileup-detection true not working with a normal control?

[Rmulet]

Hi,

I am using Mutect2 (GATK-4.6.2) to call variants in RNA-seq data that have been processed with SplitNCigar. As a result, when a variant is at the beginning or end of an exon, it is only supported by reads that start or end in that position. Apparently, this can be problematic for Mutect2, since some of these variants are not called. I attach an example below, where the first track corresponds to a tumor sample that carries a T>C mutation.

When running Mutect2 with default settings, this mutation is completely missed. However, this can be recovered by setting --pileup-detection to true in tumor-only mode. These are the stats reported by Mutect2 for this variant:

chr12	112477651	.	T	C	.	.	AS_SB_TABLE=29,21|2,4;DP=60;ECNT=1;ECNTH=1;MBQ=37,37;MFRL=4912,13285;MMQ=60,60;MPOS=45;POPAF=7.30;TLOD=16.13	GT:AD:AF:DP:F1R2:F2R1:FAD:SB	0/1:50,6:0.134:56:0,0:44,6:44,6:29,21,2,4

Unfortunately, the mutation is missed again if I run the analysis with an unmatched normal control that has no reads supporting that mutation (second track in the image below). Perhaps pileup-based haplotypes are only being used in tumor-only mode?

I have tried the suggestions in When HaplotypeCaller and Mutect2 do not call an expected variant, but nothing seems to help. I have run Mutect2 with --linked-de-bruijn-graph , --recover-all-dangling-branches or --min-pruning 0, to no avail. This is what my command looked like after trying everything I could:

Mutect2 --reference /work/ALL/genome/GRCh38.primary_assembly.genome.fa --input 6371.bam --tumor-sample 6371 --output 6371_test_control.vcf --dont-use-soft-clipped-bases --native-pair-hmm-threads 5 --read-validation-stringency LENIENT --min-read-length 1 --intervals PTPN11.bed --initial-tumor-lod 1 --disable-tool-default-read-filters --lenient --recover-all-dangling-branches --min-pruning 0 --bam-output 6371_mutect.bam --input CONTROL.bam --normal-sample CONTROL

The BAM output of this command is in the last IGV track of my image. As you can see, it is completely empty. If I set --pileup-detection to false again and generate a GVCF, this is what it looks like:

chr12	112477651	.	T	<NON_REF>	.	.	END=112477651	GT:DP:MIN_DP:TLOD	0/0:59:59:15.58

As a side note, I can only generate a GVCF without the normal, otherwise it gives me an error.

UPDATE: The number of variants with and without --pileup-detection is different, so apparently it does work in tumor/normal mode. However, I find it strange that this the variant can be detected with this setting in tumor-only mode, but not when a normal is used (even though this normal sample has no reads supporting it).

UPDATE2: after playing around with pretty much every setting of Mutect2, I have been able to detect this mutation by setting --min-dangling-branch-length to 1. But if dangling branches are indeed the issue with this variant, why doesn't --recover-all-dangling-branches work?