[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HTCondor-users] Fwd: Re: Condor & Bosco submissions


On 03/07/2013 11:42 AM, Francesco Prelz wrote:

On Thu, 7 Mar 2013, Guillermo Marco Puche wrote:

It works !

Excellent. I'll make sure that the fix gets propagated.

Next step should be how to pass those variables dynamically to SGE submit node as told in Bosco manual.


As I already said in list it's a bit confusing. I don't know if custom parameters are simply variables or they mean anything to each Grid system.

Did you get my first reply to the list (sent on Wed, 06 Mar 2013 12:00:15 +0100: I start suspecting it got lost) ?

The 'Custom' attribute machinery was introduced fundamentally at the request of CERN which, like other large sites, likes to handle (and possibly clamp) any resource request of jobs. So they deploy on their
(LSF) submit nodes a centrally managed 'lsf_local_submit_attributes.sh'
script. Now, there *is* a set of common resource attributes deployed
across the CERN/LHC computing infrastructure, but it doesn't really matter in your case, unless you plan on sending your jobs to many other sites
where you don't know the batch system configuration. 'Custom' here really
means that these attributes are shared between the submit and execute
nodes, nothing else.

Looking at the SGE attributes you are setting:

1) The queue choice has a dedicated submit attribute: if you
   set +remote_queue in your submit file, this will translate into
   a queue name setting valid for any batch system.

2) -V, environment export: there is an alternative path for getting
   the environment via condor_submit (try setting getenv=true in the
   submit file).

3) -cwd : this shouldn't change anything for these jobs, as they will
   move to a specific subdir and bring all needed files with them.

4) -pe : the only thing that we could somewhat standardize across
   all batch systems so far was the request of N nodes for MPI jobs
   (that you can obtain by setting +remote_nodenumber). If you need
   something more specific, this is indeed where a 'custom' attribute may
   come in handy. You could call it something like 'sge_pe_argument'.

5) -j y : if you really need to mix stdout and stderr (it's uncommon
   that one really needs to so that), that could also warrant an
   attribute like 'sge_merge_stdout_stderr'.

6) -N: another custom attribute like 'sge_job_name' may work.

Assuming that you choose those names, your sge_local_submit_script.sh
would look like this:

#Unquote if necessary
eval unquoted_sge_pe_argument=$sge_pe_argument
if [ -n "$unquoted_sge_pe_argument" ]; then
 echo "#\$ -pe $unquoted_sge_pe_argument"

if [ -n "$sge_job_name" ]; then
 echo "#\$ -N $sge_job_name"

if [ $sge_merge_stdout_stderr -ne 0 ]; then
 echo "#\$ -j y"

then you can trigger those switches by (optionally) setting in the submit file

+remote_cequirements = unquoted_sge_pe_argument == "orte 8" && sge_job_name == "aln_bosco" && sge_merge_stdout_stderr == 1
+remote_queue = all.q

Does this make sense ?

This makes lot of sense. I'm going to try out some different configs to see what suits the best for me.
Again, thank you very much for your help.

I hope changes are propagated for next Bosco release since SGE custom properties were not working.
If any of Bosco developers are aware of this mail please notify me or the mailing list, I'll report to them if I don't get any answer from them.

Best regards,

Francesco P.

g.marco: Informatician at Sistemas Genómicos S.L
phone: 0034635197460
web: www.sistemasgenomicos.com