Notice:
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.
Attention:
We will be out of the office on October 14, 2019, due to the U.S. holiday. We will return to monitoring the forum on October 15.

[possible-bug] GATK 3.4-46 CombineGVCFs is wrongly assigning * at -1 position of some intervals

We found that whenever the previous interval ends in a deletion, GATK is extending upstream 1 base the following interval and wrongly adds the * call to it. In most cases this will be a non-issue as you will filter downstream analysis with the same interval files and these lines won't be included. Still it looks like a bug the team might want to look into.

Also we are running CombineGVCFs in "BP_RESOLUTION" mode. Not sure if this makes a difference.

A couple of examples:

#CHROM  POS ID  REF ALT QUAL    FILTER  INFO
1   100330153   .   C   <NON_REF>   .   .   .
1   100330154   .   T   <NON_REF>   .   .   .
1   100330155   .   TC  T,<NON_REF> .   .   BaseQRankSum=-0.572;ClippingRankSum=0;DP=14876;MQ=60;MQRankSum=-1.067;ReadPosRankSum=0.572
1   100335944   .   T   *,<NON_REF> .   .   DP=8
1   100335945   .   T   <NON_REF>   .   .   .
1   100335946   .   T   <NON_REF>   .   .   .

#CHROM  POS ID  REF ALT QUAL    FILTER  INFO
1   215916683   .   AAGAG   A,AAG   9405.15 .   AC=4,81;AF=0.008547,0.173;AN=468;BaseQRankSum=-0.061;ClippingRankSum=0.1;DP=25502;FS=0;InbreedingCoeff=-0.2174;MLEAC=2,80;MLEAF=0.004274,0.171;MQ=60;MQRankSum=0.092;QD=1.25;ReadPosRankSum=-1.035;SOR=0.65
1   215916684   .   A   *,<NON_REF> .   .   DP=25594
1   215916685   .   G   *,<NON_REF> .   .   DP=25593
1   215916686   .   A   *,<NON_REF> .   .   DP=25128
1   215916687   .   G   *,<NON_REF> .   .   DP=25115
1   215931925   .   T   *,<NON_REF> .   .   DP=65
1   215931926   .   T   <NON_REF>   .   .   .
1   215931927   .   T   <NON_REF>   .   .   .

Relevant lines in the interval file:

1   100329930   100330155   AGL 0   +
1   100335944   100336147   AGL 0   +
1   215916507   215916687   USH2A   0   -
1   215931925   215932104   USH2A   0   -

Thanks,
Carlos

Tagged:

Answers

  • SheilaSheila admin Broad InstituteMember, Broadie, Moderator admin

    @CarlosBorroto
    Hi Carlos,

    I am not sure I follow what you are saying. Do you mean position 1:100335944 does not have a deletion in the GVCF, but in the Combined GVCF, it shows a deletion (*)? If so, then that is a bug and I will need you to submit some test files.

    Thanks,
    Sheila

  • CarlosBorrotoCarlosBorroto ✭✭ Member ✭✭

    Hi @Sheila,

    Yes, in the samples above positions 1:100335944 and 1: 215931925 are called as deletion but I don't think they are. I will collect test files and upload them to the FTP.

    --Carlos

Sign In or Register to comment.