Bug Bulletin: we have identified a bug that affects indexing when producing gzipped VCFs. This will be fixed in the upcoming 3.2 release; in the meantime you need to reindex gzipped VCFs using Tabix.

Data Processing Pipeline: re-aligning from BAMs

dparkdpark Posts: 9Member
edited January 2013 in Ask the team

I had a question that, while it might be more appropriate for a BWA or seqanswers audience, I noticed something in the GATK's "Data Processing Pipeline" under "Methods and Workflows" that made me wonder. The pipeline is described here and there's a nice flowchart as well: http://www.broadinstitute.org/gatk/guide/topic?name=methods-and-workflows#41

The process describes a BAM of reads that are either not aligned or aligned by some process you don't want to use, so the first step seems to be Picard's RevertSam and then a realignment with BWA. I'm wondering why the process described by this GATK document splits it into per-lane BAM files. There doesn't seem to be any process done at the per-lane level other than BWA alignment. I have two guesses.. the first was to allow more parallelization at that step.

But my second guess is that perhaps BWA doesn't play nice with read groups when reading reads from BAM input files. If that is true, that would explain why I'm having trouble with BAM (a single sample, multiple lanes, merged into one file) -> BWA -> realigned-BAM -> GATK (either UnifiedGenotyper or RealignerTargetCreator, etc)--somewhere along the way, read groups are getting lost. So my guess is that the above-described pipeline splits it per-lane so it can manually respecify read groups all over again to BWA?

Is that other people's experience as well?

Also, the Methods and Workflows page describes a Queue script, but there's no link or anything to the actual Queue script. Anyone know where to find it?

Danny

Post edited by Geraldine_VdAuwera on

Danny Park, PhD -- Broad Institute, IDI, Sabeti Lab

Best Answer

  • CarneiroCarneiro Posts: 271 admin
    Answer ✓

    Hey Danny,

    you are right on both reasons, but in the reverse order of importance.

    1. BWA wipes out all RG information so if you try to realign a whole bam that has several @RG entries (1 per lane at least) it will be impossible (or at the very least a nightmare) to reassign read groups to the appropriate reads. Doing it per lane, I can simply assign every read in each aligned bam to a single Read Group and later join them all.

    2. Smaller BAMs usually mean we can run on a faster queue and get jobs done faster. But this is really not the main reason to do this. It is reason #1. Joining everything afterwards makes any gains we get here from splitting irrelevant.

Answers

Sign In or Register to comment.