Re: [galaxy-dev] Fetch closest feature
Hello Shaun, Apologies for the delay in reply. The tool Operate on Genomic Intervals - Fetch closet non-overlapping feature currently still only returns non-overlapping results, from any of the four options. No changes are planned for the near-term. To identify overlapping intervals, you are correct that using the other Interval tools would be appropriate. Then, if you wanted both overlapping and non-overlapping data together in a single result dataset, a workflow would be a great solution to do the processing. Thank you for your patience! And thanks for using Galaxy! Best, Jen Galaxy team On 12/13/10 12:27 PM, SHAUN WEBB wrote: Hi, I remember a post a while ago about the fetch closest feature tool requesting that the output returns overlapping features rather than just the nearest up/downstream feature. Was this ever implemented? Perhaps as a different tool? Would the easiest alternative be to create a workflow from existing tools (join- filter out intervals that have a join - fetch closest feature - concatenate output files)? Thanks for your help Shaun Webb -- Jennifer Jackson http://usegalaxy.org ___ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Re: [galaxy-dev] Easy download/setup of Bacterial Genbank and multiple alignment files from UCSC?
On Wed, Jan 12, 2011 at 1:15 AM, Paszkiewicz, Konrad k.h.paszkiew...@exeter.ac.uk wrote: Hi all, Many thanks for that Peter. It worked a charm. There does seem to be a bug in there somewhere. If more than one item is selected for retrieval at a time, only a single item is returned. The other items all return a 'This file cannot be found' error. Given Dan's comments earlier, that doesn't surprise me. Is this on your local Galaxy (I didn't get as far that before Christmas), or on the main Penn State instance? Finally as an aside, could this system be adapted to retrieve the PTT files from Genbank? You certainly could use the PTT files to get the gene CDS co-ordinates, but as I recall the scripts just extract this information from the GenBank files (*.gbk) instead. All the very best, Konrad. Peter ___ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
[galaxy-dev] bowtie hanging after execution
Hi All, I am seeing a strange problem with Galaxy and bowtie. Here is the scenario: 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, not bowtie_wrapper. Any help would be greatly appreciated. Cheers -- Branden Timm University of Wisconsin Great Lakes Bioenergy Research Center bt...@glbrc.wisc.edu ___ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Re: [galaxy-dev] bowtie hanging after execution
Branden, 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. Regards, Kelly On Jan 12, 2011, at 5:32 PM, Branden Timm wrote: Hi All, I am seeing a strange problem with Galaxy and bowtie. Here is the scenario: 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, not bowtie_wrapper. Any help would be greatly appreciated. Cheers -- Branden Timm University of Wisconsin Great Lakes Bioenergy Research Center bt...@glbrc.wisc.edu ___ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev ___ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
