Juan, I'm sure you are running up against errors with Bowtie and BWA, but we had to suppress the error output of the tools because it is also used for non-error output (and therefore stops the tool sometimes when it should not). First, check that the PATH variable has the right paths to your Bowtie and BWA installations. If that doesn't help, if you can share your history with me (kpvincent@bx.psu.edu ), I can try running your data without error output suppression, and see what I find. Alternatively, if you would rather do this yourself, it's actually very easy. In the tools/sr_mapping/bowtie_wrapper.py file, remove the "2> /dev/null" from the relevant command. The indexing command is on line 96 and the aligning command is on line 140 (paired-end data) or 142 (single-end). The same can be done for BWA (tools/sr_mapping/ bwa_wrapper.py): indexing--line 68, aligning--lines 97, 100, 101, and 103. Once you've done this, just run the tool as normal in the browser. Any output that goes to stderr will show up in the history. Thanks, Kelly On Nov 2, 2009, at 5:14 PM, juan perin wrote:
I see that I was mistakenly assuming the FASTX toolkit was provided with Galaxy. I had installed it a while back and forgot. It now works fine having placed it properly where the nodes can see it. I'm now onto another issue.
This time, I can't get bwa or bowtie to provide a valid alignment. I've tried several different fastq files, yet they all end up giving me the same output:
"empty, format: sam, database:Info:" I'm using data that has worked fine for us outside of galaxy, however this won't run for me in the browser. I can't find any other error messages anywhere. I have tried two different human genome databases. One that was pre-indexed for bowtie from the bowtie website, and the other was an hg18 version i indexed using bowtie manually. Neither works for me.
Any ideas on what I might be doing wrong, or what might be happening would be very much appreciated. Even if someone might point me in the right direction, as to what logs to be looking at. To note, the galaxy interface does not report an 'error' per se. It just gives me no results, and the output i pasted above.
Thanks in advance.
juan
On Fri, Oct 30, 2009 at 4:32 PM, Nate Coraor <nate@bx.psu.edu> wrote: juan perin wrote:
Actually, i did not want to use file staging. I am running from my home directory which is visible on all nodes, and has plenty of space for my needs. I'm guessing I did something in the config to activate file staging, in which case that would explain the error that shouldn't be. I didn't read closely enough, but I set:
# The PBS options are described in detail in the Galaxy Configuration section of # the ClusteringGalaxy Wiki, and are only necessary when using file staging. pbs_application_server = variome pbs_stage_path = /home/perin/galaxy-dist/database/tmp pbs_dataset_server = variome
which obviously caused issues as a result. Commenting this back cleared it up, but introduced another issue, where the nodes apparently don't see the binary it is trying to run. I was assuming that the binaries were located in the home directory I was running from, but now see that they are actually in /usr/local/bin/etc... I'm not sure where this is set, but assume it was done sometime during the setup.sh process. Is there a way I can specify this install location, or change it anywhere? I can copy the binaries over to the nodes, but would prefer to host them in a shared place. Is there a way to change Galaxy so that it looks in say "/share/apps/ bin/" instead of /usr/local/bin ?
Do you mean the binaries for the dependencies? If so, they are expected to be found on the $PATH, so if that's consistent on the Galaxy server and the nodes, you should be okay.
Otherwise, I'm not sure which binaries you're referring to.
_______________________________________________ galaxy-dev mailing list galaxy-dev@bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev