Bowtie2 doesn't align paired-end sequences
I'm trying to map two paired-end fastq.gz files, which were previously trimmed by Trimmomatic and re-paired by BBmap, using Bowtie2. Reads were originally exome sequencing data. Set GRCh38 as reference genome. Yet, it doesn't yield a map, giving an alignment rate of 0%. This is what I get:
Time loading reference: 00:00:00 Time loading forward index: 00:00:00
Time loading mirror index: 00:00:01 Multiseed full-index search:
00:00:00 0 reads
0.00% overall alignment rate Time searching: 00:00:01 Overall time: 00:00:01
If you want to examine my code:
bowtie2 -t -x ref\GRCh38_noalt_as\GRCh38_noalt_as -1 data\repaired_1.fastq.gz -2 data\repaired_2.fastq.gz -S data\mapped_1.bam
Searching on the forums, but couldn't sort out why it doesn't work.
Note that same reads were mapped on usegalaxy.org with no problem. It didn't even require repairing step somehow.
0 answers
No answers yet.
Log in to answer this question.
More posts like this
-
why 99% reads failed to align in mir-seq analysis?
written by mohammadhassanj
-
I cannot obtain summary alignment with Bowtie2
written by alejandra.pando •
-
How To Extract Reads-Pairs Aligned Concordantly Exactly 1 Time from Bowtie2 (version 2.3.4.1 or hig…
written by Chilly •
-
Bowtie produced empty .sam file
written by melissachua90 •
-
Bowtie: Find the tradeoffs between seed length argument
written by melissachua90 •
-
HISAT2 no properly paired alignments
written by cengiz •
-
Why my reads mapping rate extremely low
written by LeeLee •
-
Aligning multiple fastq files in Bowtie2
written by vineethmails •
-
HISAT2 : Differences in paired and unpaired rates
written by gwe3409 •
-
alignment rate in bowtie2
written by zizigolu
Trimmed and repaired, that would not be necessary if trimming was done properly in paired-end mode in the first place. Please show the code for that, the error likely is there.
On Galaxy, it could be mapped without repairing. But when I try to map on Bowtie2 after trimming step, it says that one of the reads contains fewer bases than other. As suggested by other users here, I performed a re-pairing step as well.
Here is my code for Trimmomatic:
FastQC showed me that there was no over-represented sequences or adapters. Then I only performed quality trimming.
Report for trimming: