Regarding MergeBam tool of Picard

[amitm]

hi all,
A seemingly simple task of merging BAMs has flummoxed me. Picard MergeBamAlignment module has a mandatory option of UNAMAPPED_BAM file.

I am using bwa aln and it doesn't return separately any unmapped file. I couldn't understand this parameter. Is this module supposed to be used only if one has unmapped BAMs too.

Anyways, another Picard module: MergeSamFiles, says it can merge BAMs too and doesn't require unmapped BAMs.

I spent so much time understanding the former; thought anyone else looking at these modules should be aware too.

[MBekritsky]

From Picard MergeBamAlignment--
UNMAPPED_BAM - Original SAM or BAM file of unmapped reads, which must be in queryname order.

You must give MergeBamAlignment the original sequences you aligned using bwa aln in BAM or SAM format, sorted by read ID.

I haven't used this command before, and it's not clear to me what purpose it serves. I'm sure these is a reason for it, I just haven't come across it yet.

In any case, if you have multiple output BAMs that you'd like to merge post-alignment, perhaps the best choice is MergeSamFiles. If I were you, I'd add a read group to each file separately before merging them. You can do that using Picard's AddOrReplaceReadGroups.

[amitm]

hi MBekritsky,
Its not clear as UNMAPPED_BAM is asking for a BAM file and not original sequence file which would be a fastq. The aligner which I know that writes out separate BAM for unmapped seq. is TopHat (Not sure of the recent versions though).

Ya, I did passed the readgroup info at the bwa sampe stage. There were multiple lanes and wanted to combine the final BAMs.

thanks

[MBekritsky]

Hi amitm,

I regularly deal with unaligned reads in BAM format. It's a little odd, since BAM is meant to store alignment information, but it's not uncommon, since it allows you to store read pairs in the same file and compresses the data. You can get from FASTQ to BAM (or SAM) format using Picard's FastqToSam.

The line regarding what UNMAPPED_BAM requires is a direct quote from the Picard website. It seems to be simply asking for the unmapped reads initially passed to BWA for alignment. I don't see the same ambiguity that you do, but I also haven't been spending as much time on it as you do, so I will defer to you.

Lastly, if all you want to do is combine the final BAMs, why not use MergeSamFiles? That works very well and doesn't have the requirement for UNMAPPED_BAM as an input.

[dpryan]

Picard's MergeBamAlignment tool is poorly named and I doubt you're the first person to wonder about this. A better name would have been IncorporateUnmapped.

[MBekritsky]

So it's for use with alignment algorithms that don't report unmapped reads?

[dpryan]

There are a couple uses (that I know of at least). Firstly, it can be convenient to merge in unmapped reads and then just archive the resulting BAM file rather than archiving a BAM file having only mapped reads and a fastq file. Secondly, some downstream tools (particularly RNAseqQC) need to know the total number of initial reads you had in order to produce correct output.

BTW, the description in the original email mentioning this tools is informative here:

- MergeBamAlignment - Tool to take a Sam or Bam file of unmapped
reads and merge it with a Sam or Bam file that contains alignment
information for a subset of those reads, retaining all metadata from the
unmapped file.

So originally some of the developers were using BAM files to hold unmapped reads (this can be convenient) and then wanted to merge back in the unmapped reads. Yeah, it'd make sense to just have the aligner spit the unmapped reads out, but that's not always an option (really, who has the time to muck with every aligner's code).