Yes it isand my galaxy is up to date.
Thanks,
Liisa
From:
Nate Coraor
To:
Liisa Koski
Cc:
galaxy-dev@lists.bx.psu.edu
Date:
01/30/2012 03:07 PM
Subject:
Re: [galaxy-dev] Error Setting BAM Metadata
On Jan 25, 2012, at 2:43 PM, Liisa Koski wrote:
> Hello,
> I am trying to upload BAM f
yep, that works. modifying it to only display with 'input dataset' makes
sense.
Just curious, but how stable is the workflow API for IO nodes? For instance, I
could see creating a custom input node for splitting data for parallel
processing, then combining processed data into a final report
On Feb 1, 2012, at 9:45 AM, Lucilla Luzi wrote:
> Thank you Nate,
>
> maybe there is something that I'm still missing...
>
> When I type what you suggest, I get again an error message that is
>
> $ python scripts/fetch_eggs.py
> Traceback (most recent call last):
> File "scripts/fetch_eggs.py
Oh, I see what you're doing, thanks for clarifying. Add an Input Dataset step
and it should work fine. The original intent for multiple input scaling was
really designed explicitly for that scenario using the Input Dataset workflow
steps and the fact that it works for some tools directly was a
Minimal case is a single-node workflow with FastQC (tophat also had the same
problem):
http://test.g2.bx.psu.edu/u/cjfields/w/test
maybe it's tool-specific?
chris
On Feb 3, 2012, at 1:10 AM, Dannon Baker wrote:
> Can you share a workflow that's failing for you on test with me? I just
> tri
Hello Ira,
Thanks for reporting this - there are several similar issues that I've
corrected in my next change set, which will be available today. This change
set will introduce tool versioning for Galaxy tools, whether they are installed
from a tool shed, or are available with the distribution
Hi Alex,
The ToolSectionLabel element is causing the problem as it is not currently
supported in the new tool shed repository installation implementation. I'll
try to get a fix for this today. In the meantime, eliminating the section
label from your tool config should work as a temporary work
Somehow I seem to miss something when configuring our latest up-to-date
galaxy_central version to use the galaxy toolshed.
When as admin I want to install a tool I can browse the given 2 repositories
and select view tools.
When I select install to local galaxy it drops an error on 2 tools I teste
On Fri, Feb 3, 2012 at 11:55 AM, Ryan Golhar
wrote:
> 'qstat -f | grep jobname' will give you the full jobname without truncation.
Sadly not on our version of SGE - which appears to be SGE 6.2u5 - you
get a bit more information but the job name is still truncated as before.
> Personally, I thin
'qstat -f | grep jobname' will give you the full jobname without
truncation. Personally, I think the qstat reporting gives too little
information. I've written a perl script to parse the output of qstat -f to
give a bit more information. So truncation of jobnames for qstat shouldn't
be an issue.
Hello all,
We're not planning to try the new "run cluster jobs as user"
functionality (at least, not just yet), so for now all our SGE jobs
show on the cluster via qstat or any other monitoring tool as
belonging to the user "galaxy".
Currently the jobs are submitted as shell scripts "galaxy_NNN.s
Restricting datasets to show only the first megabyte is a great idea
when dealing with large data files but sometimes I want to see the end
of a file to check it is complete or to check the progress of a
running job. At the moment I use the helper script to find the file on
the server and
On Thu, Feb 2, 2012 at 6:29 PM, Nate Coraor wrote:
> On Feb 2, 2012, at 12:22 PM, Nate Coraor wrote:
>>
>> Ahh, I see what's going on here. The drm out/err files are now
>> being written to the job working directory, which is cleaned up at
>> the end of the job wrapper's finish method, before the
13 matches
Mail list logo
