Hello,
I am running second round of BaseRecalibrator, using the output table generated from first round of BaseRecalibrator (pretty much the similar command, except in a second run, I use -BQSR <table_from_first_round_of_BaseRecalibrator>
). During the bam file processing procedure, the program quits and spews out this message:
##### ERROR stack trace
net.sf.picard.PicardException: Unable to load 1(179574784, 180576784) from /projects/seqdev/ysong_snp_indel/hg19a_reference.fa
at net.sf.picard.reference.IndexedFastaSequenceFile.getSubsequenceAt(IndexedFastaSequenceFile.java:205)
at org.broadinstitute.sting.utils.fasta.CachingIndexedFastaSequenceFile.getSubsequenceAt(CachingIndexedFastaSequenceFile.java:284)
at org.broadinstitute.sting.gatk.datasources.providers.ReferenceView.getReferenceBases(ReferenceView.java:116)
at org.broadinstitute.sting.gatk.datasources.providers.ReadReferenceView$Provider.getBases(ReadReferenceView.java:87)
at org.broadinstitute.sting.gatk.contexts.ReferenceContext.fetchBasesFromProvider(ReferenceContext.java:145)
at org.broadinstitute.sting.gatk.contexts.ReferenceContext.getBases(ReferenceContext.java:189)
at org.broadinstitute.sting.gatk.walkers.bqsr.BaseRecalibrator.calculateIsSNP(BaseRecalibrator.java:335)
at org.broadinstitute.sting.gatk.walkers.bqsr.BaseRecalibrator.map(BaseRecalibrator.java:253)
at org.broadinstitute.sting.gatk.walkers.bqsr.BaseRecalibrator.map(BaseRecalibrator.java:132)
at org.broadinstitute.sting.gatk.traversals.TraverseReadsNano$TraverseReadsMap.apply(TraverseReadsNano.java:228)
at org.broadinstitute.sting.gatk.traversals.TraverseReadsNano$TraverseReadsMap.apply(TraverseReadsNano.java:216)
at org.broadinstitute.sting.utils.nanoScheduler.NanoScheduler.executeSingleThreaded(NanoScheduler.java:274)
at org.broadinstitute.sting.utils.nanoScheduler.NanoScheduler.execute(NanoScheduler.java:245)
at org.broadinstitute.sting.gatk.traversals.TraverseReadsNano.traverse(TraverseReadsNano.java:102)
at org.broadinstitute.sting.gatk.traversals.TraverseReadsNano.traverse(TraverseReadsNano.java:56)
at org.broadinstitute.sting.gatk.executive.LinearMicroScheduler.execute(LinearMicroScheduler.java:108)
at org.broadinstitute.sting.gatk.GenomeAnalysisEngine.execute(GenomeAnalysisEngine.java:313)
at org.broadinstitute.sting.gatk.CommandLineExecutable.execute(CommandLineExecutable.java:113)
at org.broadinstitute.sting.commandline.CommandLineProgram.start(CommandLineProgram.java:245)
at org.broadinstitute.sting.commandline.CommandLineProgram.start(CommandLineProgram.java:152)
at org.broadinstitute.sting.gatk.CommandLineGATK.main(CommandLineGATK.java:91)
##### ERROR ------------------------------------------------------------------------------------------
##### ERROR A GATK RUNTIME ERROR has occurred (version 2.8-1-g932cd3a):
##### ERROR
##### ERROR This might be a bug. Please check the documentation guide to see if this is a known problem.
Just to include more detail, I am running this in a local server with following command:
java -Xmx8g -jar GenomeAnalysisTK-2.8-1/GenomeAnalysisTK.jar \
-T BaseRecalibrator \
-R <reference_fasta.fa> \
-I <bam_file_generated_from_IndelRealigner> \
-BQSR <table_from_round_1_of_BaseRecalibrator> \
-o <output_table_from_round_2_of_BaseRecalibrator> \
-knownSites <vcf_file_from_GATK_bundle>
More specifically, <vcf_file_from_GATK_bundle>
is 1000G_omni2.5.b37.vcf
. I could put more vcf into the analysis, but decided to play safe and use one file for now.
Nonetheless, has anyone encountered such issue?
The error message suggests that it can't get the reference sequence on chromosome 1 between 179574784 and 180576784. You might check that that range exists and ensure that the .fai file matches the .fa file (just remake the fasta index).
See also this post on the GATK forum.
hmm, so that's what it meant 1(179574784, 180576784)...although I've been using the same .fa and .fai file for the past three GATK commands and they seemed to be okay. I am in a process of re-running this right now, and if it does throw a same message, then I might try recreating the .fai file
so the second time running the second phase...it actually processed the chr1 regions mentioned in the previous error and its progressing...very strange indeed.