This is the command I used to run MuTect:
/usr/bin/java -Xmx4g -Djava.io.tmpdir=tmp -jar ${MuTect}mutect-1.1.7.jar \
--input_file:normal ${BQSR_dir}${Blood}.recal.bam --input_file:tumor ${BQSR_dir}${Nevus}.recal.bam \
--out ${MuTect_dir}${Blood}${Nevus}_call_stats.out \
--coverage_file ${MuTect_dir}${Blood}${Nevus}coverage.wig.txt \
--vcf ${MuTect_dir}${Blood}${Nevus}.vcf \
--analysis_type MuTect --reference_sequence ${GATK_hg} --cosmic ${COSMIC} --dbsnp ${dbSNP} --intervals ${Intervals} \
--disable_auto_index_creation_and_locking_when_reading_rods \
--min_qscore 30 --max_alt_alleles_in_normal_count 0
The results got more somatic mutations than when I run exactly same command except that I dropped the last line. So I went through all IGVs, and found that some somatic mutations identified are obviously germline mutations!
I feel so anxious. I don't have an idea how to debug this. Please any one help me.
Also, though I set --max_alt_alleles_in_normal_count 0
, MuTect is still picking up mutations. The one on upper section is for tumor, and lower section for normal.
You will inevitably get germline variants called as somatic hits, it's just a case of trying to limit how many come up. Do many of the variants come up at regions containing repetition or indels? You could reduce their influence by merging the tumour and normal data, running realignment, and then splitting them back up.
Conversely, if you look through the data yourself, do variants at TP53 / RB1 / KRAS (? not sure what the best candidate would be in your case) get identified by your workflow?