We are running Bowtie 0.12.7 currently. I've updated the wiki to
reflect the current version of the tools we're using (thanks for
letting us know it was out of date!).
On Jan 13, 2011, at 11:39 AM, Branden Timm wrote:
Thanks for the tip, Kelly - I tested this on my workstation at
revision 4640 and am seeing the same behavior. The output SAM file
is 1.9G. I will pull the latest changes from the repository and re-
By the way, is 0.12.1 still the preferred version of bowtie for
HEAD? The NGSLocalSetup page indicates so, but seems a bit
outdated. I am running 0.12.1 currently.
On 1/13/2011 12:30 AM, Kelly Vincent wrote:
Which revision of Galaxy are you using? What this sounds like is
that it is taking a long time to set the metadata on the resulting
SAM file, i.e., after the Bowtie job has run. Prior to
4698:48a81f235356 (12/1/10), all the lines in a large SAM file
would be read to determine how many lines there were--this could
take a very long time. But that changeset made it so that it gave
up if the file was too large and did not set the number of lines.
However, in 4842:7933d9312c38 (1/12/11), this was changed so that
if the file is too large, it generates a rough estimate of the
number of lines.
On Jan 12, 2011, at 5:32 PM, Branden Timm wrote:
I am seeing a strange problem with Galaxy and bowtie. Here is the
1) I run bowtie for Illumina data (bowtie 0.12.5 Linux x86_64) on
a fastqsanger input generated by FASTQ-Groomer
2) On the system, I see the bowtie_wrapper and bowtie subprocesses
start, with bowtie distributing across the four cores in the system
3) The bowtie and bowtie_wrapper processes stop a few minutes
later, but the history item still shows that it is running. This
happens for about 20 minutes. Paster.log show constant POST
history_item_updates activities every three seconds, and the
Galaxy server process itself hogs 100% of one of the system's cores.
I've tried this both on our production galaxy site (RHEL 5.5,
Python 2.4.3) and my local workstation (RHEL 6, Python 2.6.5).
As part of my troubleshooting, I've extracted the bowtie_wrapper
command from paster.log and run it on the command line. The tool
completes successfully in a few minutes, which confirms that the
Galaxy server process seems to be the culprit in this situation,
Any help would be greatly appreciated. Cheers
University of Wisconsin
Great Lakes Bioenergy Research Center
galaxy-dev mailing list
galaxy-dev mailing list