bowtie2 local alignment

[frymor]

Hi,

What are the disadvantage of local alignment mode in bowtie2?
We have a data set with very high quality reads. But when running tophat2 with the defaults parameters, even after clipping and trimming for adapter residues, I still can map only ~60-65% of the whole data set.
Than I have tried bowtie2 with the local-very-sensitive parameter and got over 99% of the reads mapped.

I was wondering, if there is anything against using bowtie2 in this modeand why other people are not doing it more often, if the results are so good.
Is it just the longer running time of the mapping step which needed to be addressed here or are there any more factors one must take under consideration, when running bowtie2 in local mode?

I know there are other mappers such as BBMap and subread, that are also able to do a local alignments and works also with shorter reads.

But what are the reason people don't really do local alignments when working with RNA-Seq data?

thanks in advance
Assa

[dpryan]

The only real downside is that it's a bit slower. It's good that you're using the --very-sensitive-local setting, since the defaults for --local are often not that great. For what it's worth, I generally get better results with STAR, though I expect hisat with --very-sensitive-local might work equally well (I've not compared them).

[frymor]

The only real downside is that it's a bit slower.

Thanks Devon for the fast reply. Does it means, I don't have to worry about False positive mapped reads? I mean not (a lot) more, than running bowtie2 in the end-to-end mode or even tophat2?

Is there any reason to worry about downstream analyses, if differential exon usage is involved?
We are also interested in testing the results with DEXSeq. There is a paper from 2011 which sort of comapred different mappers. It shows that bowtie creates a lot of FP junction site predictions.

For what it's worth, I generally get better results with STAR...

I have not tried STAR yet, but I would like to try it as well as subread and BBmap, which AFAIK can both works with gapped alignments.

though I expect hisat with --very-sensitive-local might work equally well (I've not compared them).

This is also a good suggestion I would like test and compare them.

[dpryan]

I wouldn't recommend using bowtie2 by itself, but with tophat2, since bowtie2 by itself doesn't handle splicing. Regarding junction accuracy, this is probably a better paper to go by: http://www.nature.com/nmeth/journal/...meth.2722.html

[frymor]

Yes, *that was the problem.
I have tried tophat2 and got 65% mapped reads. This is why i tried bowtie2 with local alignment.
As far as I know, *tophat2 doesn't do local alignments

[dpryan]

Yeah, I don't think there's a good way to use bowtie2 with local alignment on RNAseq data...at least without modifying tophat2. I'd personally use a different aligner for that very reason (well, plus both tophat2 and bowtie2 are a bit slow). You might check and see why end-to-end alignment is proving to be such a problem. If this is something that trimming can remedy (e.g., adapter contamination) then that might be the simplest fix.

[Brian Bushnell]

The main issue with local alignments in RNA-seq is that, depending on the scoring function, you will lose a lot of the splices. For example, say you have a 100bp read that aligns with a cigar like this:

50=10000D50=

Local alignment shouldn't change anything.

But if you have this:

85=10000D15=

...with the splice site very close to the end of the read, a local alignment would yield "85=" if the score penalty from a 10k deletion/intron was greater than the score of 15 matches. So, generally, I don't recommend local in RNA-seq alignment to a genome - or if you use local alignments, at least check to see the fraction of splice sites captured in local versus global mode. Different aligners have different weighting schemes, and some might not penalize introns at all - particularly, introns won't get penalized by any aligner if you are mapping to a transcriptome since they will not be present.