Bowtie, an ultrafast, memory-efficient, open source short read aligner

[ieuanclay]

Great, thanks. I am writing an old skool perl GUI wrapper to handle all the input and forking off several alignment runs (separate from the internal forking that bowtie already does, i.e. if i want to align 4 files, it will run them as parallel children, keeping any output separate), and saving/loading the parameters i used. It is really only for my own use, but I can send it to you if you are interested? Please tell me to bugger off if i am stepping on toes!

Ieuan

[Ben Langmead]

Originally Posted by ieuanclay

also, i just noticed a typo in the manual (0.9.9.3) : for the --fr/rf/ff docs, you call --ff --ll. Maybe this isn't a typo and i am just being really dumb...

You're absolutely right. Sorry about that. I just fixed it on the web version of the manual and in the Bowtie repository. The fix to the MANUAL file in the Bowtie download will be reflected in the next release (after 0.10.0).

Thanks,
Ben

[Ben Langmead]

Hi Ieuan,

If you don't mind sharing it, sure, please send it along. Note that the --mm option in the 0.10.0 release of Bowtie might be helpful to you if you're (a) running many concurrent bowtie processes that are searching against the same large index, and (b) memory is tight.

Thanks,
Ben

[ieuanclay]

I'll have a look, and no i don't mind sharing, as long as you promise not to laugh!

Ieuan

[inesdesantiago]

Hi lh3, you are right. The speed is dependent on the information it has to report.

For instance, I tried to run bowtie with the parameter -m set to 1 and it took 3hours, while previously it was taken 15min. I think it is very impressive that bowtie can do the alignment in 15 minutes. When I set “–m 1” bowtie will now suppress all alignments for a particular read with more then 1 alignments (while previously it doesn’t suppress any alignment). I believe that, by setting a limit to –m, bowtie has to process more information and thus takes more time..

Originally Posted by lh3

The speed of Eland/Maq will remain the same if we do not ask them to report the counts because they check them anyway, but the speed of Bowtie/SOAP2/BWA will be reduced a lot..

Perhaps MAQ should have some more optional parameters. For e.g. we could choose to have all the reports we have now in MAQ, or we could choose to make it faster with less counts and so on… This would be great.

[inesdesantiago]

Hi lh3, you are right. The speed is dependent on the information it has to report.

For instance, I tried to run bowtie with the parameter -m set to 1 and it took 3hours, while previously it was taken 15min. I think it is very impressive that bowtie can do the alignment in 15 minutes. When I set “–m 1” bowtie will now suppress all alignments for a particular read with more then 1 alignments (while previously it doesn’t suppress any alignment). I believe that, by setting a limit to –m, bowtie has to process more information and thus takes more time..

Quote:
Originally Posted by lh3
The speed of Eland/Maq will remain the same if we do not ask them to report the counts because they check them anyway, but the speed of Bowtie/SOAP2/BWA will be reduced a lot..


Perhaps MAQ should have some more optional parameters. For e.g. we could choose to have all the reports we have now in MAQ, or we could choose to make it faster with less counts and so on… This would be great.

[chuck]

Hi Ben,

Wanted to report that bowtie does not ever 'finish', i.e. return the command line prompt and in 'top' it reports as still active, even though it has not written anything to file in a long time.

I saw this first on one machine but thought it was just something wrong with my install but now I have seen it on two machines. Are you familiar with this? I suppose it could still be something about my install.

I am running it in Ubuntu 8.04 on an IBM Intellistation (64-bit machine).

Chuck

[Ben Langmead]

Originally Posted by inesdesantiago

When I set “–m 1” bowtie will now suppress all alignments for a particular read with more then 1 alignments (while previously it doesn’t suppress any alignment). I believe that, by setting a limit to –m, bowtie has to process more information and thus takes more time..

Note that a way to make this alignment scenario (-m 1 without --best --strata) far more efficient is to use a repeat-masked reference index and omit the -m 1 option.

Ben

[Ben Langmead]

Originally Posted by chuck

Wanted to report that bowtie does not ever 'finish', i.e. return the command line prompt and in 'top' it reports as still active, even though it has not written anything to file in a long time.

Hi Chuck,

Please post the exact Bowtie version and arguments you're using. Also, please let me know if you see this problem when you use the latest version of Bowtie (0.10.0).

Thanks,
Ben

[ewingad]

Originally Posted by Ben Langmead

Note that a way to make this alignment scenario (-m 1 without --best --strata) far more efficient is to use a repeat-masked reference index and omit the -m 1 option.

Ben

Would it also be valid use the -k 2 option and throw out reads for which two alignments are reported? This is slower than alignment against a masked genome but faster than -m 1.

[Ben Langmead]

Originally Posted by ewingad

Would it also be valid use the -k 2 option and throw out reads for which two alignments are reported? This is slower than alignment against a masked genome but faster than -m 1.

Absolutely, as long as you're using -k 2 in an unstratified reporting mode (the default in 0.10.0). Obviously, stratified -k 2 is not a good proxy for unstratified -m 1.

I would be surprised if unstratified -k 2 performed all that differently from unstratified -m 1, since what's going on under the hood is essentially the same. Do you have an example where it is? If so, I should take a look.

Ben

[ewingad]

Originally Posted by Ben Langmead

Absolutely, as long as you're using -k 2 in an unstratified reporting mode (the default in 0.10.0). Obviously, stratified -k 2 is not a good proxy for unstratified -m 1.

I would be surprised if unstratified -k 2 performed all that differently from unstratified -m 1, since what's going on under the hood is essentially the same. Do you have an example where it is? If so, I should take a look.

Ben

Actually now that I benchmark it, -m 1 is slightly faster than -k 2 using 0.10.0.

-Adam

[kcook]

Hi all,

I'm using Bowtie to map some RNA-seq data, and I wanted to clarify my understanding of a couple points.

The behaviour of -m 1 with default (0.10.0) parameters will only report results for which there is only one alignment anywhere within the 2-mismatch limit, right? So if there is an alignment with one mismatch and one with two, nothing will be reported. And if --strata is on, then the one-mismatch alignment will be reported (as long as there is only a single alignment with one mismatch). Is that all correct?

Also, the rounding of quality values to between 10 and 30 means that there is no combination of two mismatches that give a total quality score of 70, so in effect the quality scores only affect the order of the results returned (which doesn't apply when -m 1 is on anyway). Have I got that right?

Thanks a lot, and I apologize if any of this is explained in the manual or otherwise obvious.

Kate

[Ben Langmead]

Hi Kate,

Originally Posted by kcook

Hi all,
The behaviour of -m 1 with default (0.10.0) parameters will only report results for which there is only one alignment anywhere within the 2-mismatch limit, right? So if there is an alignment with one mismatch and one with two, nothing will be reported. And if --strata is on, then the one-mismatch alignment will be reported (as long as there is only a single alignment with one mismatch). Is that all correct?

Yes - that's all correct.

Also, the rounding of quality values to between 10 and 30 means that there is no combination of two mismatches that give a total quality score of 70, so in effect the quality scores only affect the order of the results returned (which doesn't apply when -m 1 is on anyway). Have I got that right?

The quality ceiling only applies in the -n ("Maq-like") alignment mode. So your statement is still correct for -v 2, but it's also the case that in -v 3 mode, alignments with combined mismatch qualities exceeding 70 are valid.

I hope that helps,
Ben

[kcook]

Great! Thanks for the quick reply.

[inesdesantiago]

Hello,

Originally Posted by kcook

Hi all,

I'm using Bowtie to map some RNA-seq data, and I wanted to clarify my understanding of a couple points.

The behaviour of -m 1 with default (0.10.0) parameters will only report results for which there is only one alignment anywhere within the 2-mismatch limit, right? So if there is an alignment with one mismatch and one with two, nothing will be reported. And if --strata is on, then the one-mismatch alignment will be reported (as long as there is only a single alignment with one mismatch). Is that all correct?

Also, the rounding of quality values to between 10 and 30 means that there is no combination of two mismatches that give a total quality score of 70, so in effect the quality scores only affect the order of the results returned (which doesn't apply when -m 1 is on anyway). Have I got that right?

Thanks a lot, and I apologize if any of this is explained in the manual or otherwise obvious.

Kate

kcook, you illuminated me! Now I anderstand the -m 1 better!

[chuck]

Ben,

It still seems to be doing this. When I look at the *map file, it obviously ends without properly finishing, as you can see from the last line.

SOLEXA8_38_8_100_1783_191_0_2/2 - Castanea 105274 GATCCGTATCATCTTGACTTGGTTCTGATTTCTCTATTTTTTTAAGAATAC IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 0
SOLEXA8_38_8_100_1783_586_0_1/1 + Castanea 107330 CGTTACCTTAACCACAAGGAGGGGGATGCCGAAGGCAGGGCTAGTGACTGG IIIIII

Originally Posted by Ben Langmead

Hi Chuck,

Please post the exact Bowtie version and arguments you're using. Also, please let me know if you see this problem when you use the latest version of Bowtie (0.10.0).

Thanks,
Ben

I just downloaded the latest version last night (0.10.0.2).

The job statement is as follows:

./bowtie -f Castmoll_cp -1 /media/upuna/LH0002/LH0002_302MJAAXX_1_1.fa,/media/upuna/LH0002/LH0002_3151AAAXX_2_1.fa,/media/upuna/LH0002/LH0002_3151AAAXX_1_1.fa,/media/upuna/LH0002/LH0002_3151AAAXX_3_1.fa -2 /media/upuna/LH0002/LH0002_302MJAAXX_1_2.fa,/media/upuna/LH0002/LH0002_3151AAAXX_2_2.fa,/media/upuna/LH0002/LH0002_3151AAAXX_1_2.fa,/media/upuna/LH0002/LH0002_3151AAAXX_3_2.fa /media/upuna/LH0002/LH2_all_castmoll.map

Thanks,
Chuck

[Ben Langmead]

Hi Chuck,

Originally Posted by chuck

Ben,

It still seems to be doing this. When I look at the *map file, it obviously ends without properly finishing, as you can see from the last line.

Could you try the same command but using 'bowtie-debug' instead of 'bowtie'? If possible, pick a set of parameters where (a) 'bowtie' hangs and (b) the run doesn't take very long.

Thanks,
Ben

[chuck]

Originally Posted by Ben Langmead

Could you try the same command but using 'bowtie-debug' instead of 'bowtie'? If possible, pick a set of parameters where (a) 'bowtie' hangs and (b) the run doesn't take very long.

Ben,

I don't seem to have a ./bowtie-debug command - I made this from the source code on a 64-bit machine.

Chuck

[Ben Langmead]

Originally Posted by chuck

Ben,

I don't seem to have a ./bowtie-debug command - I made this from the source code on a 64-bit machine.

Chuck

Hi Chuck - sorry, just do 'make bowtie-debug' and that should create it.

Ben