Hello,
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.
https://twiki.grid.iu.edu/bin/view/CampusGrids/BoscoInstall#CustomScriptLocations
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"
fi
if [ -n "$sge_job_name" ]; then
echo "#\$ -N $sge_job_name"
fi
if [ $sge_merge_stdout_stderr -ne 0 ]; then
echo "#\$ -j y"
fi
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,
Guillermo.
Francesco P.
|