We’re moving the GATK website, docs and forum to a new platform. Read the full story and breakdown of key changes on this blog.
If you happen to see a question you know the answer to, please do chime in and help your fellow community members. We encourage our fourm members to be more involved, jump in and help out your fellow researchers with their questions. GATK forum is a community forum and helping each other with using GATK tools and research is the cornerstone of our success as a genomics research community.We appreciate your help!
Test-drive the GATK tools and Best Practices pipelines on Terra
Check out this blog post to learn how you can get started with GATK and try out the pipelines in preconfigured workspaces (with a user-friendly interface!) without having to install anything.
We will be out of the office for a Broad Institute event from Dec 10th to Dec 11th 2019. We will be back to monitor the GATK forum on Dec 12th 2019. In the meantime we encourage you to help out other community members with their queries.
Thank you for your patience!
curious zero quality reference calls around indels
I have been looking the HC output of my "haploid" Drosophila genomes. Mostly great. But there is one pattern that I neither understand or can even rationalize in the context of the many discussions of the complexity the gatk BP pipeline. Here is a typical call (including a bamout):
| DPGP3b_ZI99_GATKBP @ rooted3 (chuck) | => gatk \ | => -T HaplotypeCaller \ | => -R /home/chuck/shrd/reference_genomes/D_mel_RELEASE6_Sue/dmel_r6.fasta \ | => -I DPGP3b_ZI99.sorted.dm.rg.recal.bam \ | => --genotyping_mode DISCOVERY \ | => --emitRefConfidence BP_RESOLUTION \ | => -hets 0.006 \ | => --indel_heterozygosity 0.0006 \ | => --minReadsPerAlignmentStart 5 \ | => --output_mode EMIT_ALL_CONFIDENT_SITES \ | => --sample_ploidy 1 \ | => -kmerSize 10 \ | => -kmerSize 25 \ | => --doNotRunPhysicalPhasing \ | => --dontTrimActiveRegions \ | => --variant_index_type LINEAR \ | => --variant_index_parameter 128000 \ | => -o DPGP3b_ZI99.2L12-13M.raw.snps.indels.g.vcf \ | => -L 2L:12000000-13000000 \ | => -bamout DPGP3b_ZI99.2L12-13M.sorted.dm.rg.recal.bamout.bam &
And here is a small example
2L 12020924 . A <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:99:0,135 2L 12020925 . A <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:99:0,135 2L 12020926 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:89:0,90 2L 12020927 . G <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:89:0,90 2L 12020928 . C <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:89:0,90 2L 12020929 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:89:0,90 2L 12020930 . A <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:89:0,90 2L 12020931 . C <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:0:0,0 2L 12020932 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:13,0:13:0:0,0 2L 12020933 . A AT,<NON_REF> 219.78 . DP=13;MLEAC=1,0;MLEAF=1.00,0.00;MQ=60.00 GT:AD:DP:GQ:PL:SB 1:0,13,0:13:99:252,0,252:0,0,8,5 2L 12020934 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:3,11:14:0:0,0 2L 12020935 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:14,0:14:99:0,391 2L 12020936 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:14,0:14:99:0,389 2L 12020937 . T <NON_REF> . . . GT:AD:DP:GQ:PL 0:17,0:17:99:0,479
A number of other examples are in the attached file along with the std output to the terminal from HC.
Many of these cases of GQ == 0 seem arbitrary and surprising, but I know there is a lot going on under the hood.
Is this to be expected? If not, what can I do to improve the high quality calling.
Let me know if you would like to have the input bam files.