Re: [galaxy-dev] Setting up Galaxy with SGE
On Wed, Jun 15, 2011 at 2:30 AM, Ka Ming Nip km...@bcgsc.ca wrote: Hello, I have been trying to set up Galaxy to run its jobs on my SGE cluster using the Unified Method, based on the steps described in the wiki: https://bitbucket.org/galaxy/galaxy-central/wiki/Config/Cluster My local instance of Galaxy is installed under my home directory, but my cluster is on a different file system. I need to ssh to the head node before I can submit jobs. Is there any way to set up Galaxy with a SGE cluster on a different file system? I haven't looked into it in great detail, but we currently have a similar network setup, and would also like to link Galaxy to SGE. The main problem is the lack of a shared file system - in order to run a job on the cluster we (Galaxy) has to get the data onto the cluster, run the job, and get the results back. Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] [galaxy-user] Error running latest Galaxy Distribution: numpy.dtype exception
On Jun 15, 2011, at 3:36 PM, Kanwei Li wrote: What is the version for numpy in your eggs.ini? eggs.ini has numpy = 1.3.0. I have no local edits this is just a clean checkout of galaxy-dist. ~Mike On Wed, Jun 15, 2011 at 3:14 PM, Michael Steder ste...@ci.uchicago.edu wrote: Hi Nate, On Jun 15, 2011, at 12:18 PM, Nate Coraor wrote: It should be working, this would have been a problem for a short time using galaxy-central, but should not have affected -dist. Could you send the output of: python ./scripts/get_platforms.py python -V $ python ./scripts/get_platforms.py macosx-10.6-universal-ucs2 $ python -V Python 2.6.1 Should I be running galaxy-central instead? No, galaxy-dist is fine (and should be less prone to issues due to cloning/updating at the wrong moment). Thanks, --nate Just in case it helps: I'm currently running tip of galaxy-dist: hg tip changeset: 5585:8c11dd28a3cf tag: tip user:Nate Coraor n...@bx.psu.edu date:Thu May 19 10:07:53 2011 -0400 summary: Add Picard and fastqc tools to Main My prior version which is still working for me is: changeset: 5355:50e249442c5a user:Daniel Blankenberg d...@bx.psu.edu date:Thu Apr 07 08:39:07 2011 -0400 summary: Additional fix for typo propagated from manual_builds, which was updated in 5350:cd2aff5b117c. ~Mike ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Setting up Galaxy with SGE
Hi We have been able to get the following setup working pretty reliably: Automated deployment of Galaxy clusters on EC2. These clusters have the following setup: A NFS server providing global directories for home directories, software, and scratch space. We are also experimenting with glusterfs A NIS server providing an authentication domain within the cluster. The list of users must be specified when the cluster is created A GridFTP server, which is automatically registered as a Globus Online (www.globusonline.org) endpoint for high speed and reliable data transfer. Ability to script transfer tasks as part of the workflow using Globus Online Galaxy tools (To get large quantities of data in and out of galaxy EC2 cluster reliably) A Condor pool with jobs running using user's credentials (using users accounts that are provisioned in the EC2 cluster) A Galaxy server with the modifications outlined above, which we plan to contribute back to the galaxy community soon I gave a talk at the recent Galaxy users conference about this setup. You can find slides here: PowerPoint Please let me know if you are interested and would like more information. Regards On Jun 15, 2011, at 5:28 AM, Marina Gourtovaia wrote: There are two slightly different problems here. One with the files ystem and the second is whether the machine Galaxy is running on can submit jobs to the cluster (ssh is mentioned in the original e-mail, suggesting that it's impossible to communicate with the cluster from the machine the job is running on). The Galaxy instance is constantly communicating with the cluster job scheduling system (SGE or other) in order to get updates on the status of the jobs. It should be possible to do it over ssh, but, in my experience, this slows down the code. We run the Galaxy server on one of the cluster nodes. I imagine that other people using Galaxy with the cluster do the same. Are they? Marina On 15/06/2011 08:51, Peter Cock wrote: On Wed, Jun 15, 2011 at 2:30 AM, Ka Ming Nipkm...@bcgsc.ca wrote: Hello, I have been trying to set up Galaxy to run its jobs on my SGE cluster using the Unified Method, based on the steps described in the wiki: https://bitbucket.org/galaxy/galaxy-central/wiki/Config/Cluster My local instance of Galaxy is installed under my home directory, but my cluster is on a different file system. I need to ssh to the head node before I can submit jobs. Is there any way to set up Galaxy with a SGE cluster on a different file system? I haven't looked into it in great detail, but we currently have a similar network setup, and would also like to link Galaxy to SGE. The main problem is the lack of a shared file system - in order to run a job on the cluster we (Galaxy) has to get the data onto the cluster, run the job, and get the results back. Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- Ravi K Madduri The Globus Alliance | Argonne National Laboratory | University of Chicago http://www.mcs.anl.gov/~madduri ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Setting up Galaxy with SGE
Ravi, Do your galaxy jobs submit to the cluster as the galaxy user or as the user? Thanks, Ilya Sent from my iPhone On Jun 15, 2011, at 2:43 PM, Ravi Madduri madd...@mcs.anl.govmailto:madd...@mcs.anl.gov wrote: Hi We have been able to get the following setup working pretty reliably: * Automated deployment of Galaxy clusters on EC2. These clusters have the following setup: * A NFS server providing global directories for home directories, software, and scratch space. We are also experimenting with glusterfs * A NIS server providing an authentication domain within the cluster. The list of users must be specified when the cluster is created * A GridFTP server, which is automatically registered as a Globus Online (http://www.globusonline.orgwww.globusonline.orghttp://www.globusonline.org) endpoint for high speed and reliable data transfer. * Ability to script transfer tasks as part of the workflow using Globus Online Galaxy tools (To get large quantities of data in and out of galaxy EC2 cluster reliably) * A Condor pool with jobs running using user's credentials (using users accounts that are provisioned in the EC2 cluster) * A Galaxy server with the modifications outlined above, which we plan to contribute back to the galaxy community soon I gave a talk at the recent Galaxy users conference about this setup. You can find slides here: PowerPointhttp://wiki.g2.bx.psu.edu/GCC2011?action=AttachFiledo=gettarget=GalaxyGridFTPCondorAndGlobusOnline.pptx Please let me know if you are interested and would like more information. Regards On Jun 15, 2011, at 5:28 AM, Marina Gourtovaia wrote: There are two slightly different problems here. One with the files ystem and the second is whether the machine Galaxy is running on can submit jobs to the cluster (ssh is mentioned in the original e-mail, suggesting that it's impossible to communicate with the cluster from the machine the job is running on). The Galaxy instance is constantly communicating with the cluster job scheduling system (SGE or other) in order to get updates on the status of the jobs. It should be possible to do it over ssh, but, in my experience, this slows down the code. We run the Galaxy server on one of the cluster nodes. I imagine that other people using Galaxy with the cluster do the same. Are they? Marina On 15/06/2011 08:51, Peter Cock wrote: On Wed, Jun 15, 2011 at 2:30 AM, Ka Ming Nipmailto:km...@bcgsc.cakm...@bcgsc.camailto:km...@bcgsc.ca wrote: Hello, I have been trying to set up Galaxy to run its jobs on my SGE cluster using the Unified Method, based on the steps described in the wiki: https://bitbucket.org/galaxy/galaxy-central/wiki/Config/Clusterhttps://bitbucket.org/galaxy/galaxy-central/wiki/Config/Cluster My local instance of Galaxy is installed under my home directory, but my cluster is on a different file system. I need to ssh to the head node before I can submit jobs. Is there any way to set up Galaxy with a SGE cluster on a different file system? I haven't looked into it in great detail, but we currently have a similar network setup, and would also like to link Galaxy to SGE. The main problem is the lack of a shared file system - in order to run a job on the cluster we (Galaxy) has to get the data onto the cluster, run the job, and get the results back. Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ http://lists.bx.psu.edu/ -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/http://lists.bx.psu.edu/ -- Ravi K Madduri The Globus Alliance | Argonne National Laboratory | University of Chicago http://www.mcs.anl.gov/~maddurihttp://www.mcs.anl.gov/~madduri ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] The new hg based Galaxy Tool Shed
I apologize for jumping on to this thread a bit late. I read below that there is a plan to pull tools into a galaxy installation automagically. I wonder if you plan on providing some kind of API to query the tool registry and discover the tools and install them into an existing galaxy installation. PS: The link : How to upload, download and install tools under Help seems to be broken. On Jun 1, 2011, at 3:00 PM, Nate Coraor wrote: Peter Cock wrote: Well, use of the dependency system isn't required, so just setting things up on the $PATH is always a possibility. I was going to suggest that your patch could be applied if it was conditional on the local runner and checked after any requirement type=package dependencies were setup, ... Is that a request for me to update the patch? I've not delved into the job runner code before, so it might take me a bit longer that it would take you. Hint hint ;) I'd help with testing though. It's not a completely trivial thing, which is why I didn't do it at the time. It's probably something that should be added to the DRM wrapper script so that a nice error message can be supplied. I can't think of a way to check at tool load that wouldn't be painfully slow. ... but there's still the problem of people running jobs through the local runner which are actually sent to the cluster without Galaxy's knowledge. Perhaps this is something we shouldn't worry too much about, but I know there are people doing it. You mean if Galaxy blindly calls a tool or script, and that script then submits the job to the cluster? I'd say checking the cluster dependencies there was the tool author's responsibility. Yeah, that's the idea. Unfortunately, if the binary isn't installed on the Galaxy server (which is irrelevant), the tool won't load, which is certainly not what we want. --nate Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- Ravi K Madduri The Globus Alliance | Argonne National Laboratory | University of Chicago http://www.mcs.anl.gov/~madduri ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
