We've moved!
This site is now read-only. You can find our new documentation site and support forum for posting questions here.
Be sure to read our welcome blog!

HaplotypeCaller: genome loc merge error

chapmanbchapmanb Boston, MAMember ✭✭
edited August 2012 in Ask the GATK team

Hi all;
I'm trying out the HaplotypeCaller and running into an error. A small
reproducible BAM file is here:

https://s3.amazonaws.com/chapmanb/haplotype-problem-4.bam

Running with:

java -jar GenomeAnalysisTK.jar -T HaplotypeCaller -I haplotype-problem-4.bam -R human_g1k_v37.fasta -o tmp-small.vcf -debug

Results in:

Assembling 4:49139433-49139677 with 27 reads:    (with overlap region = 4:49139368-49139742)
INFO  09:40:05,438 GATKRunReport - Uploaded run statistics report to AWS S3 
##### ERROR ------------------------------------------------------------------------------------------
##### ERROR stack trace 
org.broadinstitute.sting.utils.exceptions.ReviewedStingException: The two genome loc's need to be contigous
        at org.broadinstitute.sting.utils.GenomeLoc.merge(GenomeLoc.java:144)
        at org.broadinstitute.sting.utils.GenomeLoc.union(GenomeLoc.java:181)
        at org.broadinstitute.sting.utils.activeregion.ActiveRegion.add(ActiveRegion.java:45)
        at org.broadinstitute.sting.gatk.walkers.haplotypecaller.HaplotypeCaller.finalizeActiveRegion(HaplotypeCaller.java:513)
        at org.broadinstitute.sting.gatk.walkers.haplotypecaller.HaplotypeCaller.map(HaplotypeCaller.java:391)
        at org.broadinstitute.sting.gatk.walkers.haplotypecaller.HaplotypeCaller.map(HaplotypeCaller.java:107)
        at org.broadinstitute.sting.gatk.traversals.TraverseActiveRegions.processActiveRegion(TraverseActiveRegions.java:245)
        at org.broadinstitute.sting.gatk.traversals.TraverseActiveRegions.callWalkerMapOnActiveRegions(TraverseActiveRegions.java:201)
        at org.broadinstitute.sting.gatk.traversals.TraverseActiveRegions.processActiveRegions(TraverseActiveRegions.java:176)
        at org.broadinstitute.sting.gatk.traversals.TraverseActiveRegions.endTraversal(TraverseActiveRegions.java:278)
        at org.broadinstitute.sting.gatk.executive.LinearMicroScheduler.execute(LinearMicroScheduler.java:81)
        at org.broadinstitute.sting.gatk.GenomeAnalysisEngine.execute(GenomeAnalysisEngine.java:265)
        at org.broadinstitute.sting.gatk.CommandLineExecutable.execute(CommandLineExecutable.java:113)
        at org.broadinstitute.sting.commandline.CommandLineProgram.start(CommandLineProgram.java:236)
        at org.broadinstitute.sting.commandline.CommandLineProgram.start(CommandLineProgram.java:146)
        at org.broadinstitute.sting.gatk.CommandLineGATK.main(CommandLineGATK.java:93)
##### ERROR ------------------------------------------------------------------------------------------
##### ERROR A GATK RUNTIME ERROR has occurred (version 2.1-3-g8892c10):
##### ERROR
##### ERROR Please visit the wiki to see if this is a known problem
##### ERROR If not, please post the error, with stack trace, to the GATK forum
##### ERROR Visit our website and forum for extensive documentation and answers to 
##### ERROR commonly asked questions http://www.broadinstitute.org/gatk
##### ERROR
##### ERROR MESSAGE: The two genome loc's need to be contigous
##### ERROR ------------------------------------------------------------------------------------------

For some purely speculative guessing that may or may not help, the 5th
read from the bottom in the alignment looks out of whack:

image

Please let me know if I can provide any other details to help.

Best Answer

  • rpoplinrpoplin ✭✭✭
    Accepted Answer

    Hi Brad,

    This is now fixed in the lastest internal development version of the GATK and will be pushed out with the next release. Thank you very much for all your help with identifying this problem.

    Cheers,

Answers

  • rpoplinrpoplin Member ✭✭✭

    Hey Brad,

    Thanks for the report and the bam file that reproduces it. The problem seems to be from all the hard clipping in the novoalign data that isn't currently being handled correctly by the HaplotypeCaller/GATK-Engine. I'll let you know when I've nailed down a fix for this.

    Cheers!

  • rpoplinrpoplin Member ✭✭✭
    Accepted Answer

    Hi Brad,

    This is now fixed in the lastest internal development version of the GATK and will be pushed out with the next release. Thank you very much for all your help with identifying this problem.

    Cheers,

  • chapmanbchapmanb Boston, MAMember ✭✭

    Ryan -- brilliant, thank you. Looking forward to testing this out with the next release.

  • chapmanbchapmanb Boston, MAMember ✭✭

    Ryan;
    Does 2.1-8 have this fix? I ran into the same error on testing. It would be useful to expose a change log for the closed source code since it's tough to tell what changes went into new releases. I noticed the public code has a fix for the typo so was hoping these went in together. If I should keep waiting for a release, just let me know. Thanks again for all the help.

  • rpoplinrpoplin Member ✭✭✭

    Hi Brad,

    Sorry that I wasn't clear. This fix is in our latest internal development version so it will be released with our next major release (v2.2). The change log on github does include commit messages from the closed sources modules but we'll try to work on providing more informative messages.

    Thanks,

  • chapmanbchapmanb Boston, MAMember ✭✭

    Ryan;
    Ah sorry, my mistake. Is 2.2 scheduled already or still a work in progress? Alternatively, is there an easy workaround for this problem other than manually -XLing the failing regions? If it's a few reads I could identify and exclude that would be a nice way to move forward, or is it just worth waiting?

  • rpoplinrpoplin Member ✭✭✭

    The release of 2.2 is still at least several weeks away. Unfortunately your data type (very sporadic coverage and lots of hard clipped reads) seems to exacerbate the problem. If you really want to try to move forward with using the HaplotypeCaller one thing you could try is filtering out the reads that are majority hard clipped away. They aren't really providing any information to the calling process anyway.

    I hope that helps,

Sign In or Register to comment.