question about bowtie result and time

[Ms@New]

Hi,

I am running bowtie on a set of reads.

my problem is when I use option --best, it takes less time than default option. but I think it should take more time.

another problem is, when I set -n 3 (number of allowed mismatches in the seed), I get a sharp drop in percentage of mapped reads. (from 90% in n=2, it goes to 57% in n=3)

does anyone have an idea what the problem might be?

I run :
time ./bowtie -n n# -I 100 -X 300 --chunkmbs 150 --un results/unmapped hg18 -1 file1.fastq -2 file2.fastq results/aln.map

thanks

[Ben Langmead]

Hi,

I am running bowtie on a set of reads.

my problem is when I use option --best, it takes less time than default option. but I think it should take more time.

another problem is, when I set -n 3 (number of allowed mismatches in the seed), I get a sharp drop in percentage of mapped reads. (from 90% in n=2, it goes to 57% in n=3)

does anyone have an idea what the problem might be?

I run :
time ./bowtie -n n# -I 100 -X 300 --chunkmbs 150 --un results/unmapped hg18 -1 file1.fastq -2 file2.fastq results/aln.map

thanks

Hi,

--best mode isn't necessarily slower than the default mode, though it is slower much of the time.

The difference observed between -n 2 and -n 3 mode is likely due to the backtracking limit, set with --maxbts (and set to infinity with -y). As you raise --maxbts, you should see -n 3 align more reads, and with -y, you should see it align at least as many reads as -n 2.

Thanks,
Ben

[Ms@New]

thanks for the quick response.

I still have some questions,
In my case, --best is almost always faster.

may be I'm wrong, but as I remember, --best option finds the best match for the read, but the default option doesn't search all possible maps, and when it gets a reasonable answer (within maxerr, and less than -n mismatches in seed) reports it.
I'm probably wrong, but that's why I have difficulty understanding why --best takes less time.