Hi Ivan, Okay - this should in principle be straightforward from what I know. A few comments below which may help clarify the situation - most of which you may know already. My apologies if you already know all of this - in case, feel free to ignore this email. 1. Ganga and Dirac do not actually care about whether your application is single or multi-core. All they do is to send your job to a particular queue in a particular site. On a personal level, I like both of them and would use Ganga if possible as it makes it easier for a new user to get started quickly. 2. On the grid, a given queue at a site should have all the machines giving the same "type" of resources (queue length, OS, ...). So, if you want to submit a multi-core job, this should go to a queue supporting multi-core job slots. Otherwise, the site admins will be a little unhappy. 3. Following point 2 above, the question is now to find out which queue supports multi-core jobs. The site administrator will help here normally. There is a special case of "ARC" CEs which run with Condor as the batch system. In this case, the same queue apparently supports all possible varieties of jobs and it is for us to submit the job with the correct options. In case of this last issue (which I suspect it is!) the DIRAC administrator of the instance you are using (Daniela / Simon) will be able to tell you exactly what to do. The solution they will probably adopt is to create a new "site" (say for example "LCG.MultiCoreSite.site") for just these multi-core jobs and ask you to submit specifically to this site. This site will automatically have the correct options to request the needed resources (queue length, RAM, # cores, etc) from the site. Then, you will need an additional line in your ganga job along the lines of j.backend.settings['Destination'] = 'LCG.MultiCoreSite.site'. Hope this helps! Cheers, Raja. On 06/07/17 13:04, Dr Ivan D. Reid wrote:
On Thu, 6 Jul 2017, Raja Nandakumar wrote:
Hi Ivan,
For my curiosity, how do you actually submit a job? Do you use Ganga or the DIRAC api directly?
Currently I'm using Ganga, tho' Simon tells me he finds it easier to use direct commands.
What I'm trying to do (and have a small amount of money towards my salary for) is set up a pilot project for "Big Data" for a bioinformatics group here at Brunel. Trying to think back to what I've heard about such things from GRIDPP meetings, I dredged up the keywords "ganga" and "dirac" so that's what I'm going for at present. The aim is to make it as simple as possible for non-Grid scientists (who seem to know python).
As a (totally non-debugged as yet!) example, here's my first pass that I came up with for this multi-core submission just before lunch:
cat submit_spades.py import os exefile=('spades.sh') os.system('chmod +x %s' % exefile) j=Job() j.backend=Dirac() j.application=Executable() j.application.exe=File(exefile) j.inputfiles=[ LocalFile('bin.tgz'), DiracFile('LFN:gridpp/user/i/ivan.reid/embl/SRR2099924_1.fastq.gz', DiracFile('LFN:gridpp/user/i/ivan.reid/embl/SRR2099924_2.fastq.gz') ] j.outputfiles= [ LocalFile('contigs.fasta.gz'), LocalFile('scaffolds.fasta.gz') ] j.submit()
cat spades.sh #!/bin/sh tar -xvzf bin.tgz time bin/spades.py -k 21,33,55,77 --careful --pe1-1 SRR2099924_1.fastq.gz --pe1-2 SRR2099924_2.fastq.gz -o spades_output -t 8 gzip spades_output/contigs.fasta gzip spades_output/scaffolds.fasta mv spades_output/*.gz .
Of course, if anyone spots some obvious bug/miscomprehension in that, it could save me some debug time...
Regards, Raja.
Cheers, ivan