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.
is it necessary to run GATK tools for .bams with GATK-related @PG entries
newGATKuser
CaseMember ✭
Hi GATK Team,
I'm analyzing WGS data from the TCGA. Looking at the header of the .bam files, I see the following @PG entries:
@PG ID:GATK TableRecalibration VN:1.6-2-gc2b74ec CL:default_platform=illumina force_platform=null window_size_nqs=5 solid_recal_mode=SET_Q_ZERO solid_nocall_strategy=THROW_EXCEPTION context_size=8 homopolymer_nback=7 recal_file=D1DVJACXX-4.csv preserve_qscores_less_than=5 smoothing=1 max_quality_score=50 doNotWriteOriginalQuals=false no_pg_tag=false fail_with_no_eof_marker=false skipUQUpdate=false Covariates=[ReadGroupCovariate, QualityScoreCovariate, CycleCovariate, DinucCovariate]
@PG ID:GATK TableRecalibration.1 VN:1.6-2-gc2b74ec CL:default_platform=illumina force_platform=null window_size_nqs=5 solid_recal_mode=SET_Q_ZERO solid_nocall_strategy=THROW_EXCEPTION context_size=8 homopolymer_nback=7 recal_file=C1940ACXX-1.csv preserve_qscores_less_than=5 smoothing=1 max_quality_score=50 doNotWriteOriginalQuals=false no_pg_tag=false fail_with_no_eof_marker=false skipUQUpdate=false Covariates=[ReadGroupCovariate, QualityScoreCovariate, CycleCovariate, DinucCovariate]
@PG ID:GATK TableRecalibration.2 VN:1.6-2-gc2b74ec CL:default_platform=illumina force_platform=null window_size_nqs=5 solid_recal_mode=SET_Q_ZERO solid_nocall_strategy=THROW_EXCEPTION context_size=8 homopolymer_nback=7 recal_file=D1DFCACXX-1.csv preserve_qscores_less_than=5 smoothing=1 max_quality_score=50 doNotWriteOriginalQuals=false no_pg_tag=false fail_with_no_eof_marker=false skipUQUpdate=false Covariates=[ReadGroupCovariate, QualityScoreCovariate, CycleCovariate, DinucCovariate]
@PG ID:GATK TableRecalibration.3 VN:1.6-2-gc2b74ec CL:default_platform=illumina force_platform=null window_size_nqs=5 solid_recal_mode=SET_Q_ZERO solid_nocall_strategy=THROW_EXCEPTION context_size=8 homopolymer_nback=7 recal_file=D1D4DACXX-3.csv preserve_qscores_less_than=5 smoothing=1 max_quality_score=50 doNotWriteOriginalQuals=false no_pg_tag=false fail_with_no_eof_marker=false skipUQUpdate=false Covariates=[ReadGroupCovariate, QualityScoreCovariate, CycleCovariate, DinucCovariate]
@PG ID:bwa PN:bwa VN:0.5.9-r16
@PG ID:GATK IndelRealigner VN:1.3-8-gb0e6afe CL:knownAlleles=[] LODThresholdForCleaning=5.0 consensusDeterminationModel=USE_READS entropyThreshold=0.15 maxReadsInMemory=150000 maxIsizeForMovement=3000 maxPositionalMoveAllowed=200 maxConsensuses=30 maxReadsForConsensuses=120 maxReadsForRealignment=20000 noOriginalAlignmentTags=false nWayOut=null generate_nWayOut_md5s=false check_early=false noPGTag=false keepPGTags=false indelsFileForDebugging=null statisticsFileForDebugging=null SNPsFileForDebugging=null
, which seem to show the IndelRealigner and BaseRecalibrator have already been run on the .bam. Is it safe then to skip re-running these processing steps and to use this .bam directly into downstream tools like MuTect? I noticed also that there's not a @PG for MarkDuplicates. Is it safe to assume this step was done?
Thanks a lot for your time,
Steve
Best Answers
-
pdexheimer
✭✭✭✭
I would say no across the board here. Yes, many of the pre-processing steps were run, but with version 1.6 - recalibration, at the very least, had some major modifications in 2.0 that you'll want to capture.
My guess would be that MarkDuplicates was run and the version of Picard was old enough that it didn't log a PG - you could verify that by looking for the "duplicates" flag on alignments in the bam file. But far and away the safest option would be to run everything through RevertSam and re-do the whole pre-processing process
-
pdexheimer
✭✭✭✭
I don't know, definitively. My feeling is that you're better off going to the beginning and starting over.
I wouldn't expect MD to be a problem. Doing a second round of BR should be okay in principle, but I'm not sure how the interaction of the two versions will go. The newer version adds insertion/deletion qualities, and I have no idea if the older recalibration might have messed up the model used to generate those. IR modifies the mapping quality of reads that it realigns, and I wouldn't think it would be good to stack those modifications. Also, it looks like the original run didn't supply any known indels and used what it could find in the pileup alone.
I guess, if you wanted to keep from doing everything, you may be able to revert the BQs and just rerun BQSR. But if you have the time, I still think it's safer to rerun everything and have a clean slate
-
Geraldine_VdAuwera
Cambridge, MA admin
Hi @newGATKuser,
Doing a second round of realignment around indels (jointly on the tumor-normal pair) is indeed recommended in the somatic calling workflow. This is still very important for somatic calling because the current version of MuTect, the somatic SNP caller, is a position-based caller like the old UnifiedGenotyper, and is sensitive to the same indel alignment issues. It also helps ensure that we have the same sequence representation in the normal and the tumor samples.
Note that the much improved MuTect2 is coming soon; it is basically the MuTect calling algorithm rewritten on top of the HaplotypeCaller's mechanics, so it is capable of performing local reassembly (as well as simultaneous modeling of SNPs and indels) which obviates the need for indel realignment (for the most part).
Answers
I would say no across the board here. Yes, many of the pre-processing steps were run, but with version 1.6 - recalibration, at the very least, had some major modifications in 2.0 that you'll want to capture.
My guess would be that MarkDuplicates was run and the version of Picard was old enough that it didn't log a PG - you could verify that by looking for the "duplicates" flag on alignments in the bam file. But far and away the safest option would be to run everything through RevertSam and re-do the whole pre-processing process
Hi @pdexheimer,
Thanks very much for your helpful reply. I just have a quick follow-up question. Is it critical that I RevertSam the "raw" .bam? I had not known of this tool before you mentioned it, but I now understand it serves to wipe the slate clean before I do pre-processing steps. Would the results be different if I run MarkDuplicates, IndelRealigner, BaseRecalibrator directly on the .bam without RevertSam at the beginning? Sorry if this is a naive question. I'm pretty new to GATK.
Sincerely,
Steve
I don't know, definitively. My feeling is that you're better off going to the beginning and starting over.
I wouldn't expect MD to be a problem. Doing a second round of BR should be okay in principle, but I'm not sure how the interaction of the two versions will go. The newer version adds insertion/deletion qualities, and I have no idea if the older recalibration might have messed up the model used to generate those. IR modifies the mapping quality of reads that it realigns, and I wouldn't think it would be good to stack those modifications. Also, it looks like the original run didn't supply any known indels and used what it could find in the pileup alone.
I guess, if you wanted to keep from doing everything, you may be able to revert the BQs and just rerun BQSR. But if you have the time, I still think it's safer to rerun everything and have a clean slate
Thanks @pdexheimer. I really appreciate the information. To be safe, I'll add RevertSam to the beginning of my pipeline then.
Hi again @pdexheimer,
Sorry for the continuous questions. I recently came across the PPT presentation "Somatic Variant Discovery" in the google drive:
https://drive.google.com/a/case.edu/folderview?id=0BwTg3aXzGxEDVk5RcEF3WW1SQWM&usp=sharing#
It seems to suggest doing a 2nd IndelRealigner step (using the tumor/normal pair) after per-sample pre-processing is finished. I guess I'm confused about whether stacking these steps is OK. Like you mentioned, the base qualities are changed after BQSR and IR, and BQSR and IR both depend on base qualities. It seems to me there might be a "missing" revert BQSR step in that workflow, before doing the 2nd pair-wise IR and BQSR?
Thanks for your patient help,
Steve
I don't remember that presentation off the top of my head (and don't have time to go digging right now, sorry), but a couple of thoughts:
1) IR modifies mapping qualities, not base qualities. The feedback loop you're envisioning doesn't quite exist
2) Pre-HaplotypeCaller, IR was a much more critical step - much of its functionality is wrapped up in the HC step now. I seem to remember an "if you have CPU hours to burn" step in one of the Best Practices that was to run IR over your entire cohort, to normalize the mapping of reads around indels. So maybe stacking IR runs won't hurt as much as I was thinking previously
Hi @pdexheimer, thanks for your time. I appreciate it. I see, I think I misunderstood the first time but I get it now.
Hi @newGATKuser,
Doing a second round of realignment around indels (jointly on the tumor-normal pair) is indeed recommended in the somatic calling workflow. This is still very important for somatic calling because the current version of MuTect, the somatic SNP caller, is a position-based caller like the old UnifiedGenotyper, and is sensitive to the same indel alignment issues. It also helps ensure that we have the same sequence representation in the normal and the tumor samples.
Note that the much improved MuTect2 is coming soon; it is basically the MuTect calling algorithm rewritten on top of the HaplotypeCaller's mechanics, so it is capable of performing local reassembly (as well as simultaneous modeling of SNPs and indels) which obviates the need for indel realignment (for the most part).
Hi @Geraldine_VdAuwera ,
Thank you for the information. I look forward to using MuTect2!