On Feb 13, 2012, at 11:52 AM, Fields, Christopher J wrote:
> On Feb 13, 2012, at 9:45 AM, Nate Coraor wrote:
>
>> On Feb 8, 2012, at 9:32 PM, Fields, Christopher J wrote:
>>
>>> 'samtools sort' seems to be running on our server end as well (not on the
>>> cluster). I may look into it a bit mo
On Feb 13, 2012, at 9:45 AM, Nate Coraor wrote:
> On Feb 8, 2012, at 9:32 PM, Fields, Christopher J wrote:
>
>> 'samtools sort' seems to be running on our server end as well (not on the
>> cluster). I may look into it a bit more myself. Snapshot of top off our
>> server (you can see our local
On Feb 8, 2012, at 11:58 AM, Ryan Golhar wrote:
> Hi Nate - I finally got a chance to look at this briefly, but I must admit,
> my Python skills are lacking. In the Bam class in binary.py, all I see are
> calls to
>
> proc = subprocess.Popen( args=command, shell=True, cwd=tmp_dir, stderr=open
On Feb 8, 2012, at 9:32 PM, Fields, Christopher J wrote:
> 'samtools sort' seems to be running on our server end as well (not on the
> cluster). I may look into it a bit more myself. Snapshot of top off our
> server (you can see our local runner as well):
>
> PID USER PR NI VIRT RES
On Thu, Feb 9, 2012 at 2:57 AM, Fields, Christopher J
wrote:
> Forgot to add, but this also seems tied to the same problem
> Ryan's describing. IIRC Galaxy also runs 'samtools sort' after
> certain jobs, correct?
>
> chris
This sounds like part of the "BAM grooming" (assuming that's
what the Gal
Forgot to add, but this also seems tied to the same problem Ryan's describing.
IIRC Galaxy also runs 'samtools sort' after certain jobs, correct?
chris
On Feb 8, 2012, at 8:32 PM, Fields, Christopher J wrote:
> 'samtools sort' seems to be running on our server end as well (not on the
> cluste
'samtools sort' seems to be running on our server end as well (not on the
cluster). I may look into it a bit more myself. Snapshot of top off our
server (you can see our local runner as well):
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
3950 galaxy20
Hi Nate - I finally got a chance to look at this briefly, but I must admit,
my Python skills are lacking. In the Bam class in binary.py, all I see are
calls to
proc = subprocess.Popen( args=command, shell=True, cwd=tmp_dir,
stderr=open( stderr_name, 'wb' ) )
which, to me, look like calls to exec
Just wanted to add that we have consistently seen this issue of 'samtools
index' running locally on our install. We are using SGE scheduler. Thanks for
pointing out details in the code Nate.
--
Shantanu.
On Jan 20, 2012, at 9:35 AM, Nate Coraor wrote:
> On Jan 18, 2012, at 11:54 AM, Ryan G
Galaxy shouldn't be trying to do that, but it also shouldn't cause metadata to
fail.
On Jan 20, 2012, at 10:52 AM, Ryan Golhar wrote:
> Thanks Nate. I'll play with that. Could it be that Galaxy is trying to
> reset the permissions or ownership of the imported BAM files. I'm not
> copying th
Thanks Nate. I'll play with that. Could it be that Galaxy is trying to
reset the permissions or ownership of the imported BAM files. I'm not
copying them into Galaxy, rather I am linking to them. That is the only
error I see in runner0.log that indicates any type of failure.
On Fri, Jan 20, 20
On Jan 18, 2012, at 11:54 AM, Ryan Golhar wrote:
> Nate - Is there a specific place in the Galaxy code that forks the samtools
> index on bam files on the cluster or the head node? I really need to track
> this down.
Hey Ryan,
Sorry it's taken so long, I've been pretty busy. The relevant cod
Nate - Is there a specific place in the Galaxy code that forks the samtools
index on bam files on the cluster or the head node? I really need to track
this down.
On Fri, Jan 13, 2012 at 12:54 PM, Ryan Golhar
wrote:
> I re-uploaded 3 BAM files using the "Upload system file paths.
> runner0.log s
I re-uploaded 3 BAM files using the "Upload system file paths. runner0.log
shows:
galaxy.jobs DEBUG 2012-01-13 12:50:08,442 dispatching job 76 to pbs runner
galaxy.jobs INFO 2012-01-13 12:50:08,555 job 76 dispatched
galaxy.jobs.runners.pbs DEBUG 2012-01-13 12:50:08,697 (76) submitting file
/home/
I re-uploaded 3 BAM files using the "Upload system filepaths
On Fri, Jan 13, 2012 at 10:53 AM, Nate Coraor wrote:
> On Jan 12, 2012, at 11:41 PM, Ryan Golhar wrote:
>
> > Any ideas as to how to fix this? We are interested in using Galaxy to
> host all our NGS data. If indexing on the head node
On Jan 12, 2012, at 11:41 PM, Ryan Golhar wrote:
> Any ideas as to how to fix this? We are interested in using Galaxy to host
> all our NGS data. If indexing on the head node is going to happen, then this
> is going to be an extremely slow process.
Could you post the contents of /home/galaxy/
Any ideas as to how to fix this? We are interested in using Galaxy to host
all our NGS data. If indexing on the head node is going to happen, then
this is going to be an extremely slow process.
___
Please keep all replies on the list by usin
On Wed, Jan 11, 2012 at 11:16 AM, Nate Coraor wrote:
> On Jan 11, 2012, at 10:56 AM, Ryan Golhar wrote:
>
> > it is also set to True:
> > > [galaxy@bic galaxy-dist]$ grep Ryan *.log
> > > runner0.log:galaxy.jobs WARNING 2012-01-10 22:17:26,381 Ryan Golhar -
> self.set_metadata_externally = True
>
On Jan 11, 2012, at 10:56 AM, Ryan Golhar wrote:
> it is also set to True:
> > [galaxy@bic galaxy-dist]$ grep Ryan *.log
> > runner0.log:galaxy.jobs WARNING 2012-01-10 22:17:26,381 Ryan Golhar -
> > self.set_metadata_externally = True
> >
> > Clearly something else is going on here. On my last i
>
> it is also set to True:
> > [galaxy@bic galaxy-dist]$ grep Ryan *.log
> > runner0.log:galaxy.jobs WARNING 2012-01-10 22:17:26,381 Ryan Golhar -
> self.set_metadata_externally = True
> >
> > Clearly something else is going on here. On my last import of BAM file,
> even after samtools finished i
On Jan 10, 2012, at 10:20 PM, Ryan Golhar wrote:
> On Tue, Jan 10, 2012 at 11:43 AM, Ryan Golhar
> wrote:
>
> Hi Ryan,
>
> You could check it in lib/galaxy/config.py, after it's read. By any chance,
> are you using galaxy-central vs. galaxy-dist? It's possible that due to a
> bug I recentl
On Tue, Jan 10, 2012 at 11:43 AM, Ryan Golhar
wrote:
>
>> Hi Ryan,
>>
>> You could check it in lib/galaxy/config.py, after it's read. By any
>> chance, are you using galaxy-central vs. galaxy-dist? It's possible that
>> due to a bug I recently fixed and a certain combination of options,
>> metad
On Jan 9, 2012, at 2:38 PM, Ryan Golhar wrote:
> On Fri, Jan 6, 2012 at 12:55 PM, Ryan Golhar
> wrote:
>
> This indicates that set_meta is running locally, in the runner process. Can
> you make sure there's not a typo in your config? The other possibility is
> that external metadata setting
On Fri, Jan 6, 2012 at 12:55 PM, Ryan Golhar wrote:
>
>> This indicates that set_meta is running locally, in the runner process.
>> Can you make sure there's not a typo in your config? The other
>> possibility is that external metadata setting failed and it's being retried
>> internally (if that
>
>
> This indicates that set_meta is running locally, in the runner process.
> Can you make sure there's not a typo in your config? The other
> possibility is that external metadata setting failed and it's being retried
> internally (if that was true, you'd see messages indicated such in the
> s
On Jan 5, 2012, at 2:48 PM, Ryan Golhar wrote:
> On Thu, Jan 5, 2012 at 11:59 AM, Nate Coraor wrote:
> On Jan 5, 2012, at 11:41 AM, Ryan Golhar wrote:
>
> > I set it to run on the cluster:
> >
> > [galaxy@bic galaxy-dist]$ grep upload1 universe_wsgi.runner.ini
> > #upload1 = local:///
>
> Could
On Jan 5, 2012, at 11:41 AM, Ryan Golhar wrote:
> I set it to run on the cluster:
>
> [galaxy@bic galaxy-dist]$ grep upload1 universe_wsgi.runner.ini
> #upload1 = local:///
Could you set use_heartbeat = True in the runner's config file and then check
the resulting heartbeat log files created i
I set it to run on the cluster:
[galaxy@bic galaxy-dist]$ grep upload1 universe_wsgi.runner.ini
#upload1 = local:///
On Thu, Jan 5, 2012 at 11:33 AM, Nate Coraor wrote:
> On Jan 5, 2012, at 11:29 AM, Ryan Golhar wrote:
>
> > On Jan 4, 2012, at 6:44 PM, Ryan Golhar wrote:
> >
> > > On Wed, Jan
On Jan 5, 2012, at 11:29 AM, Ryan Golhar wrote:
> On Jan 4, 2012, at 6:44 PM, Ryan Golhar wrote:
>
> > On Wed, Jan 4, 2012 at 5:17 PM, Ryan Golhar
> > wrote:
> > I'm adding Data Libraries to my local galaxy instance. I'm doing this by
> > importing directories that contain bam and bai files.
>
> On Jan 4, 2012, at 6:44 PM, Ryan Golhar wrote:
>
> > On Wed, Jan 4, 2012 at 5:17 PM, Ryan Golhar
> wrote:
> > I'm adding Data Libraries to my local galaxy instance. I'm doing this
> by importing directories that contain bam and bai files. I see the bam/bai
> files get added on the admin page
On Jan 4, 2012, at 6:44 PM, Ryan Golhar wrote:
> On Wed, Jan 4, 2012 at 5:17 PM, Ryan Golhar
> wrote:
> I'm adding Data Libraries to my local galaxy instance. I'm doing this by
> importing directories that contain bam and bai files. I see the bam/bai
> files get added on the admin page and t
>
> On Wed, Jan 4, 2012 at 5:17 PM, Ryan Golhar
> wrote:
>
>> I'm adding Data Libraries to my local galaxy instance. I'm doing this by
>> importing directories that contain bam and bai files. I see the bam/bai
>> files get added on the admin page and the Message is "This job is running".
>> qst
On Wed, Jan 4, 2012 at 5:17 PM, Ryan Golhar wrote:
> I'm adding Data Libraries to my local galaxy instance. I'm doing this by
> importing directories that contain bam and bai files. I see the bam/bai
> files get added on the admin page and the Message is "This job is running".
> qstat shows the
I'm adding Data Libraries to my local galaxy instance. I'm doing this by
importing directories that contain bam and bai files. I see the bam/bai
files get added on the admin page and the Message is "This job is running".
qstat shows the job run and complete. I checked my runner0.log and it
regi
34 matches
Mail list logo