On Thu, 12 Jul 2012, Dave Love wrote:
...
The advantage of doing PE_HOSTFILE rewriting in the starter_method is
that we can modify the job's PE_HOSTFILE variable to point to the new
file. This is useful for the MPIs and parallel applications that
already understand gridengine and directly read th
On Thu, 12 Jul 2012, Dave Love wrote:
Mark Dixon writes:
Things I think we've used starter_methods for in the past:
Gosh. You live in interesting times^Wclusters.
I've certainly had some interesting problems to tackle. Something's got to
keep me busy in funding droughts
...
* Tr
On Thu, 12 Jul 2012, Dave Love wrote:
...
I think the right thing to do is to write a customizable skeleton in
something like Python or Lua without the shell pitfalls and following
the builtin method exactly, but someone will doubtless do it in Perl to
confound me. Is there some gotcha doing tha
William Hay writes:
>> [The first non-proprietary hwloc support was in SGE, and that has
>> "slots"-type binding, useful as a default.] Cgroups are orthogonal to
>
> Apologies for the incorrect history.
Doubtless understandable given all the noise. I regretted having to
spend a day or so dupli
Mark Dixon writes:
> The advantage of doing PE_HOSTFILE rewriting in the starter_method is
> that we can modify the job's PE_HOSTFILE variable to point to the new
> file. This is useful for the MPIs and parallel applications that
> already understand gridengine and directly read that file.
What
Mark Dixon writes:
> Things I think we've used starter_methods for in the past:
Gosh. You live in interesting times^Wclusters.
> * Setting OpenMP thread affinity variables
> * Setting sensible default variables / aliases (e.g. in case of no "-V")
> * Setting hardware or service-specific variab
Mark Dixon writes:
> On Mon, 9 Jul 2012, Dave Love wrote:
> ...
>> I'm not sure I understand the problem. Is it specific to using the
>> starter method? Fluent 12 apparently works here with the standard
>> wrapper as "rsh".
>
> All I know is that it didn't work for me :)
I don't doubt it, and
On Tue, 10 Jul 2012, Reuti wrote:
...
* PE_HOSTFILE rewriting
This I would suggest to do in the start_proc_args of the PE, but it
might be personal taste of course.
-- Reuti
The advantage of doing PE_HOSTFILE rewriting in the starter_method is that
we can modify the job's PE_HOSTFILE vari
Am 10.07.2012 um 10:25 schrieb Mark Dixon:
> On Mon, 9 Jul 2012, Dave Love wrote:
> ...
>> You essentially need to mimic the built-in starter, which is why it's
>> best to hook into it instead. The mimic is straightforward as long as
>> you don't use shell and can follow the built-in code.
>>
>>
On Mon, 9 Jul 2012, Dave Love wrote:
...
I'm not sure I understand the problem. Is it specific to using the
starter method? Fluent 12 apparently works here with the standard
wrapper as "rsh".
All I know is that it didn't work for me :)
...
I guess it depends on the specification. I doubt i
On Mon, 9 Jul 2012, Dave Love wrote:
...
You essentially need to mimic the built-in starter, which is why it's
best to hook into it instead. The mimic is straightforward as long as
you don't use shell and can follow the built-in code.
What sort of things do people need to do other than firkle w
On 9 July 2012 11:09, Dave Love wrote:
> William Hay writes:
>
>>> In the case of OpenMP jobs using the #$ -v and #$ -V prefix would be
>>> superfluous as gridengine will start only one process. So the jsv method
>>> appears the only way?
>> Not sure what you mean about -v and -V. They contro
William Hay writes:
> On 6 July 2012 12:43, Mark Dixon wrote:
...
>> 1) Tightly-integrated openmpi jobs started up orted on slave nodes with a
>> $1 equal to " orted". I added something to strip initial spaces out to
>> fix. Noticed with openmpi 1.4.0.
>
> That looks lime an OpenMPI bug to me.
Am 09.07.2012 um 12:03 schrieb Dave Love:
> Reuti writes:
>
>> Oh, right. The shell is missing, so it's the executable and not the
>> shell builtin. Interesting effect. I wonder, with is done in the
>> kernel or qrsh_starter.
>
> I think it's the builtin_starter. You'd need to read the code fo
William Hay writes:
>> In the case of OpenMP jobs using the #$ -v and #$ -V prefix would be
>> superfluous as gridengine will start only one process. So the jsv method
>> appears the only way?
> Not sure what you mean about -v and -V. They control an environment
> variable which controls the
William Hay writes:
> On 6 July 2012 10:48, Dave Love wrote:
> I'm currently testing a starter_method for our cluster. So far I haven't
> found any unintended differences from how it behaves without one. Can you,
> or anyone else, suggest anything I should look out for?
You essentially need t
Reuti writes:
> Oh, right. The shell is missing, so it's the executable and not the
> shell builtin. Interesting effect. I wonder, with is done in the
> kernel or qrsh_starter.
I think it's the builtin_starter. You'd need to read the code for the
messy details.
> I mean: shell scripts in Linux
On 6 July 2012 20:10, Mark Dixon wrote:
> On Fri, 6 Jul 2012, William Hay wrote:
> ...
>> That looks lime an OpenMPI bug to me. Possible alternative ugly solution:
>> make " orted" a link to orted (or a script that execs orted). I tend to
>> think of starter_method as being a bit of a swiss-army
On Fri, 6 Jul 2012, William Hay wrote:
...
That looks lime an OpenMPI bug to me. Possible alternative ugly solution:
make " orted" a link to orted (or a script that execs orted). I tend to
think of starter_method as being a bit of a swiss-army chainsaw lets you
do a lot of things but is potenti
On 6 July 2012 12:43, Mark Dixon wrote:
> On Fri, 6 Jul 2012, William Hay wrote:
> ...
Could you give an example? Maybe it's something to fix; I'm puzzled how
eval would be the right thing.
>>>
>>> Scratch that if it's not just replacing exec by eval -- I remembered
>>> what happens if
On Fri, 6 Jul 2012, William Hay wrote:
...
Could you give an example? Maybe it's something to fix; I'm puzzled how
eval would be the right thing.
Scratch that if it's not just replacing exec by eval -- I remembered
what happens if you try to make a shell starter method that emulates the
built-
On 6 July 2012 10:48, Dave Love wrote:
> I wrote:
>
>> Mark Dixon writes:
>>
>>> My 2 pence... I generally have better luck with using eval instead of
>>> exec - I've seen a multitude of sins being passed through to my
>>> starter_method, generally when qrsh gets involved
>>> (e.g. tightly-integr
I wrote:
> Mark Dixon writes:
>
>> My 2 pence... I generally have better luck with using eval instead of
>> exec - I've seen a multitude of sins being passed through to my
>> starter_method, generally when qrsh gets involved
>> (e.g. tightly-integrated parallel jobs), which generally get coped
>>
On 5 July 2012 16:48, SLIM H.A. wrote:
> Conclusion must be that there is no way the gridengine administrator can use
> starter methods to override a setting like
>
> OMP_NUM_THREADS=3
>
> by the user in the job script.
>
> In the case of OpenMP jobs using the #$ -v and #$ -V prefix would be
>
f any) you supplied at the end of `qsub`, i.e. $1
>> inside the script
>> $3 second command_argument (if any) you supplied at the end of `qsub`,
>> i.e. $2 inside the script
>> ...
>>
>> -- Reuti
>>
>>
>>> Thanks
>>>
>>>
Am 05.07.2012 um 17:44 schrieb Dave Love:
> SLIM H.A. writes:
>
>> Thanks Reuti,
>>
>>> You could provide a startup_method for the queue(s) in question:
>>>
>>> #!/bin/sh
>>> export OMP_NUM_THREADS=$NSLOTS
>>> exec "$@"
>>
>> "@$" would expand to the startup_method arguments but these are
>>
..@gmail.com] On
>> Behalf Of William Hay
>> Sent: 05 July 2012 15:46
>> To: SLIM H.A.
>> Cc: Reuti; users@gridengine.org
>> Subject: Re: [gridengine users] export of environment variables from
>> start_proc_args
>>
>> On 5 July 2012 15:26, SLIM H.A. w
SLIM H.A. writes:
> Thanks Reuti,
>
>> You could provide a startup_method for the queue(s) in question:
>>
>> #!/bin/sh
>> export OMP_NUM_THREADS=$NSLOTS
>> exec "$@"
>
> "@$" would expand to the startup_method arguments but these are
> absent?
I don't see how they can be, unless you have some
d but the second doesn't
> because it is changed during the execution of the job.
>
> >
> >> -Original Message-
> >> From: Reuti [mailto:re...@staff.uni-marburg.de]
> >> Sent: 05 July 2012 15:10
> >> To: SLIM H.A.
> >> Cc: users
-- Reuti
>> -Original Message-
>> From: Reuti [mailto:re...@staff.uni-marburg.de]
>> Sent: 05 July 2012 15:10
>> To: SLIM H.A.
>> Cc: users@gridengine.org
>> Subject: Re: [gridengine users] export of environment variables from
>> start_proc_
Mark Dixon writes:
> My 2 pence... I generally have better luck with using eval instead of
> exec - I've seen a multitude of sins being passed through to my
> starter_method, generally when qrsh gets involved
> (e.g. tightly-integrated parallel jobs), which generally get coped
> with better that
age-
>> From: Reuti [mailto:re...@staff.uni-marburg.de]
>> Sent: 05 July 2012 15:10
>> To: SLIM H.A.
>> Cc: users@gridengine.org
>> Subject: Re: [gridengine users] export of environment variables from
>> start_proc_args
>>
>> Am 05.07.2012 um 16:06 sc
ff.uni-marburg.de]
> Sent: 05 July 2012 15:10
> To: SLIM H.A.
> Cc: users@gridengine.org
> Subject: Re: [gridengine users] export of environment variables from
> start_proc_args
>
> Am 05.07.2012 um 16:06 schrieb SLIM H.A.:
>
> > Hmmm. If OMP_NUM_THREADS is not set in the
14:48
>> To: 'Reuti'
>> Cc: users@gridengine.org
>> Subject: RE: [gridengine users] export of environment variables from
>> start_proc_args
>>
>>> $1 will be the jobscript to be started
>>> $2 first command_argument (if any) you supplied at t
age-
> From: SLIM H.A.
> Sent: 05 July 2012 14:48
> To: 'Reuti'
> Cc: users@gridengine.org
> Subject: RE: [gridengine users] export of environment variables from
> start_proc_args
>
> > $1 will be the jobscript to be started
> > $2 first command_argu
s.
Regards
Henk
> -Original Message-
> From: Reuti [mailto:re...@staff.uni-marburg.de]
> Sent: 05 July 2012 13:07
> To: SLIM H.A.
> Cc: users@gridengine.org
> Subject: Re: [gridengine users] export of environment variables from
> start_proc_args
>
> Am 05.07.2012
On Thu, 5 Jul 2012, Reuti wrote:
...
My 2 pence... I generally have better luck with using eval instead of
exec
But then you get an additional process in the chain and may split
arguments:
$ qsub -q all.q test.sh "A B" "2>5"
using `eval` you get $1=A, $2=B and you a file 5 with the error ou
On 5 July 2012 13:58, Mark Dixon wrote:
> On Thu, 5 Jul 2012, SLIM H.A. wrote:
>
>> Thanks Reuti,
>>
>>> You could provide a startup_method for the queue(s) in question:
>>>
>>> #!/bin/sh
>>> export OMP_NUM_THREADS=$NSLOTS
>>> exec "$@"
>>
>> "@$" would expand to the startup_method arguments but t
Am 05.07.2012 um 14:58 schrieb Mark Dixon:
> On Thu, 5 Jul 2012, SLIM H.A. wrote:
>
>> Thanks Reuti,
>>
>>> You could provide a startup_method for the queue(s) in question:
>>>
>>> #!/bin/sh
>>> export OMP_NUM_THREADS=$NSLOTS
>>> exec "$@"
>>
>> "@$" would expand to the startup_method argument
On Thu, 5 Jul 2012, SLIM H.A. wrote:
Thanks Reuti,
You could provide a startup_method for the queue(s) in question:
#!/bin/sh
export OMP_NUM_THREADS=$NSLOTS
exec "$@"
"@$" would expand to the startup_method arguments but these are absent?
The documentation about the starter_method is not c
inside the script
$3 second command_argument (if any) you supplied at the end of `qsub`, i.e. $2
inside the script
...
-- Reuti
> Thanks
>
> Henk
>
>> -Original Message-
>> From: Reuti [mailto:re...@staff.uni-marburg.de]
>> Sent: 04 July 2012 15:37
>
od is not clear to me, are the "job
arguments" the command_args to command in qsub?
Thanks
Henk
> -Original Message-
> From: Reuti [mailto:re...@staff.uni-marburg.de]
> Sent: 04 July 2012 15:37
> To: SLIM H.A.
> Cc: users@gridengine.org
> Subject: Re: [gridengin
SLIM H.A. writes:
> I want to constrain the number of OpenMP threads in a job from within
> GridEngine. The user should set this to $NSLOTS in the job script but can
> this be enforced by including this in a PE start script?
>
> I set a start_proc_args script "startopenmp.sh" with argument $pe_
Hi,
Am 04.07.2012 um 14:57 schrieb SLIM H.A.:
> I want to constrain the number of OpenMP threads in a job from within
> GridEngine. The user should set this to $NSLOTS in the job script but can
> this be enforced by including this in a PE start script?
>
> I set a start_proc_args script "start
may be use
#$ -v OMP_NUM_THREADS=$1
in qsub script
-v variable[=value],...
Available for/qsub/,/qrsh/ (with command argument) and
/qalter/.
Defines or redefines the environment variables to be
exported to the execution context of the job. If
I want to constrain the number of OpenMP threads in a job from within
GridEngine. The user should set this to $NSLOTS in the job script but can this
be enforced by including this in a PE start script?
I set a start_proc_args script "startopenmp.sh" with argument $pe_slots in an
openmp PE and th
46 matches
Mail list logo
