Hello everyone, I'm using TORQUE with Galaxy, and we noticed that if a tool is multithreaded, the number of needed cores is not communicated to pbs, leading to job crashes if the required resources are not available whenthe job is submitted. Therefore I modified a little the code as follows in lib/galaxy/jobs/runners/pbs.py 256 # define PBS job options 257 attrs.append( dict( name = pbs.ATTR_N, value = str( "%s_%s_%s" % ( job_wrapper.job_id, job_wrapper.tool.id, job_wrapper.user ) ) ) ) 258 mt_file = open('tool-data/multithreading.csv', 'r') 259 for l in mt_file: 260 l = string.split(l) 261 if ( l[0] == job_wrapper.tool.id ): 262 attrs.append( dict( name = pbs.ATTR_l, resource = 'nodes', value = '1:ppn='+str(l[1]) ) ) 263 attrs.append( dict( name = pbs.ATTR_l, resource = 'mem', value = str(l[2]) ) ) 264 break 265 mt_file.close() 266 job_attrs = pbs.new_attropl( len( attrs ) + len( pbs_options ) ) (sorry it didn't come out very well due to line breaking) The csv file contains a list of the multithreaded tools, each line containing: <tool id>\t<number of threads>\t<memory needed>\n And it works fine, the jobs wait for their turn properly, but information is duplicated. Perhaps there would be a way to include something similar in galaxy's original code (if it is not already the case, I may not be up-to-date) without duplicating data. I hope that helps :) Best regards, L-A ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list: http://lists.bx.psu.edu/listinfo/galaxy-dev To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

Just one little fix on line 261: 261 if ( len(l) > 1 and l[0] == job_wrapper.tool.id ): Otherwise it pathetically crashes when non-multithreaded jobs are submitted. Sorry about that. Regards, L-A Le mardi 19 avril 2011 à 14:33 +0200, Louise-Amélie Schmitt a écrit : > Hello everyone, > > I'm using TORQUE with Galaxy, and we noticed that if a tool is > multithreaded, the number of needed cores is not communicated to pbs, > leading to job crashes if the required resources are not available when > the job is submitted. > > Therefore I modified a little the code as follows in > lib/galaxy/jobs/runners/pbs.py > > 256 # define PBS job options > 257 attrs.append( dict( name = pbs.ATTR_N, value = str( "%s_%s_% > s" % ( job_wrapper.job_id, job_wrapper.tool.id, job_wrapper.user ) ) ) ) > 258 mt_file = open('tool-data/multithreading.csv', 'r') > 259 for l in mt_file: > 260 l = string.split(l) > 261 if ( l[0] == job_wrapper.tool.id ): > 262 attrs.append( dict( name = pbs.ATTR_l, > resource = 'nodes', value = '1:ppn='+str(l[1]) ) ) > 263 attrs.append( dict( name = pbs.ATTR_l, > resource = 'mem', value = str(l[2]) ) ) > 264 break > 265 mt_file.close() > 266 job_attrs = pbs.new_attropl( len( attrs ) + > len( pbs_options ) ) > > (sorry it didn't come out very well due to line breaking) > > The csv file contains a list of the multithreaded tools, each line > containing: > <tool id>\t<number of threads>\t<memory needed>\n > > And it works fine, the jobs wait for their turn properly, but > information is duplicated. Perhaps there would be a way to include > something similar in galaxy's original code (if it is not already the > case, I may not be up-to-date) without duplicating data. > > I hope that helps :) > > Best regards, > L-A > > ___________________________________________________________ > The Galaxy User list should be used for the discussion of > Galaxy analysis and other features on the public server > at usegalaxy.org. Please keep all replies on the list by > using "reply all" in your mail client. For discussion of > local Galaxy instances and the Galaxy source code, please > use the Galaxy Development list: > > http://lists.bx.psu.edu/listinfo/galaxy-dev > > To manage your subscriptions to this and other Galaxy lists, > please use the interface at: > > http://lists.bx.psu.edu/ ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list: http://lists.bx.psu.edu/listinfo/galaxy-dev To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

2011/6/2 Nate Coraor <nate(a)bx.psu.edu&gt;: > Hi Louise-Amélie, > > I haven't done anything with this code yet, but I wanted to let you know > that we'll eventually be adding it, I'm just going to change the > implementation slightly.  I'd like to merge the functionality of the csv > into an xml config I'm already working on (but haven't yet fully decided > on the syntax).  And it should be possible for tools to access these > parameters in the command line template.  A lot of our NGS tools have > the number of threads to use hardcoded in the tool config, which is bad. > > --nate On a related point, I've previously suggested a $variable could be defined for use in tool XML wrappers to set the number of threads. This number could come from a general configuration file, or perhaps via the cluster settings - the point is the tool doesn't need to know, it just gets told how many threads it is allowed.

Peter

On Thu, Jun 2, 2011 at 6:23 PM, Nate Coraor <nate(a)bx.psu.edu&gt; wrote: > Peter Cock wrote: >> On a related point, I've previously suggested a $variable could be defined >> for use in tool XML wrappers to set the number of threads. This number >> could come from a general configuration file, or perhaps via the cluster >> settings - the point is the tool doesn't need to know, it just gets told how >> many threads it is allowed. > > Yeah, that's the idea. > > job_conf.xml: > > <?xml version="1.0"?> > <job_conf> >    <destinations> >        <destination name="default" runner="local"/> >        <destination name="pbs_default" runner="pbs"> >            <native_param name="queue">batch</native_param> >        </destination> >    </destinations> >    <tools> >        <tool id="upload1" destination="default"/> >        <tool id="bowtie_wrapper" destination="pbs_default"> >            <resource type="cores">8</resource> >        </tool> >    </tools> > </job_conf> > > pbs.py then knows to translate '<resource type="cores">8</resource>' to > '-l nodes=1:ppn=8'. > > Your tool can access that value a bunch, like $__resources__.cores. > > The same should be possible for other consumables. > Sounds good. Would there be a global default setting somewhere in universe.ini or elsewhere for when job_conf.xml didn't set a value?

Peter

Peter Cock wrote: > On Thu, Jun 2, 2011 at 6:23 PM, Nate Coraor <nate(a)bx.psu.edu&gt; wrote: > > Peter Cock wrote: > >> On a related point, I've previously suggested a $variable could be > >> defined > >> for use in tool XML wrappers to set the number of threads. This

> >> could come from a general configuration file, or perhaps via the > >> cluster > >> settings - the point is the tool doesn't need to know, it just gets > >> told how > >> many threads it is allowed. > > > > Yeah, that's the idea. > > > > job_conf.xml: > > > > <?xml version="1.0"?> > > <job_conf> > >    <destinations> > >        <destination name="default" runner="local"/> > >        <destination name="pbs_default" runner="pbs"> > >            <native_param name="queue">batch</native_param> > >        </destination> > >    </destinations> > >    <tools> > >        <tool id="upload1" destination="default"/> > >        <tool id="bowtie_wrapper" destination="pbs_default"> > >            <resource type="cores">8</resource> > >        </tool> > >    </tools> > > </job_conf> > > > > pbs.py then knows to translate '<resource type="cores">8</resource>'

> > '-l nodes=1:ppn=8'. > > > > Your tool can access that value a bunch, like .cores. > > > > The same should be possible for other consumables. > > > > Sounds good. Would there be a global default setting somewhere in > universe.ini or elsewhere for when job_conf.xml didn't set a value? default_cluster_job_runner will remain for backwards compatibility, but we'll ship a sample job_conf.xml that runs everything locally by default. --nate

> > Peter >

Louise-Amélie Schmitt wrote: >> default_cluster_job_runner will remain for backwards compatibility, but >> we'll ship a sample job_conf.xml that runs everything locally by >> default. >> >> --nate > Haha, and I did that before realizing I could do just what I needed by > writing tool-specific pbs:// URLs at the end of the config file... I'm such > an idiot. Haha, okay, I don't think i even noticed since I was distracted by your implementation being a step in the way we want to go with it.

> But I really like what you did of it and I have a couple of questions. > > Concerning the single-threaded tools, what would happen if the number of > threads set in the xml file was>1 ? It'd consume extra slots, but the tool itself would just run as usual.

> Could it be possible to forbid a tool to run on a given node? Hrm. In PBS you could do it using node properties/neednodes or resource requirements. I'd have to think a bit about how to do this in a more general way in the XML. --nate

> Thanks, > L-A > > >>> Peter >>>

Hello all, Does anyone know if Galaxy can process Ion Torrent Data? Currently, it appears that Ion Torrent data is not a supported platform. I know that the data is in FastQ Sanger, so I would think there would be a way to incorporate it into one of the existing platform pipelines, but which one? Ion Torrent protocols are very similar to 454 in terms of library construction, etc. Should I use Lastz - Roche -454 mapping mode? I want to compare the Ion Torrent data with Illumina data (from the same DNA), so perhaps I should use the illumina workflow. Any insight would be very helpful, Thanks, Mike Dufault ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list: http://lists.bx.psu.edu/listinfo/galaxy-dev To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/