bowtie mapping

[morning latte]

Hello,

This is my first time to use bowtie and have trouble with running it and interpreting the output.

Below is the command I used.
bowtie index -f fastafile > output

The number of reads with at least one reported alignment is less than 1%. Please help me if there is anyway that I can try to improve it. Thanks.

[dpryan]

Try blasting a few of the reads that don't map and see what pops up. It's unusual in this day and age to see someone mapping a fasta file, is this old data?

[morning latte]

Thanks for q quick respond.
No, it is not old data. It was generated from Illumina Hiseq. I convert fastq files to fasta file to reduce size of the dataset. Sounds like quality information of fastq files affects bowtie mapping? In that case, should I use fastq files? Thanks again.

[dpryan]

Yes, use the fastq files. Also, use the quality information to perform quality trimming (trim adapters while you're doing that). Have a look at trimmomatic or trim_galore if you're unfamiliar with trimming reads.

[morning latte]

Thanks.

I used quality information for quality trimming. Before assembly, I transformed fastq files to fasta files. Could you explain a bit why fastq files is more useful than fasta for bowtie mapping? In the meanwhile let me try mapping with fastq files.

[dpryan]

Ah, so you're trying to map against a reference that you assembled with these same reads? I'm surprised that that yielded such a poor result.

Fastq files are generally more useful for mapping as the base-calling quality can be used to moderate mismatch penalties. Suppose you have a read with two equally good alignments, each having a single mismatch, but at different positions. If alignment #1 has the mismatch at a base with a high Phred score while alignment #2 has its mismatch at a base with a low Phred score, then alignment #2 is more likely to be correct (since the mismatch base was more likely to have been miscalled). It's not unusual for there to be slight quality dips near the end of reads, so utilising this information helps deal with that. Having said that, I wouldn't hold my breath that this will help in your situation. Perhaps something went amiss with your assembly. If there's a related organism, you might try mapping against that just for comparison. If the alignments are better, then the assembly is probably just bad.

[swbarnes2]

Yeah, everyone keeps the fastqs as fastqs, people don't throw away the quality data. Once upon a time, the SRA actually wanted the four channel quality data, not just the single quality number.

So stop converting them.

But notice that most aligners will work with gzipped fastqs. So just keep them compressed. And notice that your .bam contains all the information that your original fastq has, (or with bowite default, the mapped .bam + the unmapped .bam) so once you make those .bams, you can archive the original fastq, if you want.

[morning latte]

Sorry that I replied late. I really appreciated your advices.