Aha - I think we have a misunderstanding. Please see comments below:
On 11/28/06 8:14 PM, "Maestas, Christopher Daniel" <cdmaest_at_[hidden]>
> Thanks for the feedback Ralph. Comments below.
> -----Original Message-----
> From: users-bounces_at_[hidden] [mailto:users-bounces_at_[hidden]] On
> Behalf Of Ralph Castain
> Sent: Tuesday, November 28, 2006 3:27 PM
> To: Open MPI Users
> Subject: Re: [OMPI users] Pernode request
> We already have --pernode, which spawns one process per node. You can
> also launch one process/slot across all available slots by simply not
> specifying the number of processes.
> Cdm> I think I originally requested the -pernode feature. :-) I've seen
> one issue I know of ...
> When used in the following manner:
> "mpiexec -pernode -np N" and if N is > allocated nodes, it should error
> out and not proceed. I need to update/learn to update the trac ticket
> on this.
This is an incorrect usage - the "pernode" option is only intended to be
used without any specification of the number of processes. Pernode instructs
the system to spawn one process/node across the entire allocation - we
simply ignore any attempt to indicate the number of processes.
I suppose I could check and error out if you specify the number of procs AND
--pernode. I would have to check the code, to be honest - I may already be
doing so. Just don't remember :-)
> I gather this option would say "spawn N procs/node across all nodes" - I
> can understand the possible usefulness, but I'm not sure when we would
> get to it. Also, it isn't clear from the discussion how it differs from
> our "spawn one proc/slot" option - unless you either (a) don't want to
> use all the available processors, or (b) want to oversubscribe the
> nodes. Are either of those something people really would want to do on a
> frequent enough basis to justify another command line option?
> Cdm> I was only thinking as we see dual/quad core processors on nodes
> where this would be helpful. Something I would see wanting to do in a
> scaling/profiling study with this is hitting on (a) since we tend to do
> that to find out sweet spots and get measurements. Although I can see
> the case for (b) to easily oversubscribe by some extra count and see
> what happens there too. This and the -pernode feature I think make it
> easy not to have to keep count on the -np when you allocate N nodes.
> You can just run it on your allocated set. We tend to submit 1000s of
> jobs running varying benchmarks and parsing the output and do have users
> wanting to allocate on a pernode basis without the worry of the -np
> based on their N size.
It sounds then like having the capability of spawning one proc/slot and
doing pernode (separately, of course) covers the main options of interest.
> Just asking for clarity - I don't have any a priori opposition to the
> Cdm> it was more my hope that OSC mpiexec and Open MPI mpiexec options
> would eventually merge into common options. A guy can dream can't he?
Guess that's up to the MPI folks on the team - from an RTE perspective, I
don't have an opinion either way.
> users mailing list