Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Query regarding OMPI_MCA_ns_nds_vpid env variable
From: Ralph H Castain (rhc_at_[hidden])
Date: 2008-07-11 10:01:10

On 7/11/08 7:50 AM, "Ashley Pittman" <apittman_at_[hidden]>

> On Fri, 2008-07-11 at 07:42 -0600, Ralph H Castain wrote:
>> On 7/11/08 7:32 AM, "Ashley Pittman" <apittman_at_[hidden]>
>> wrote:
>>> On Fri, 2008-07-11 at 07:20 -0600, Ralph H Castain wrote:
>>>> This variable is only for internal use and has no applicability to a user.
>>>> Basically, it is used by the local daemon to tell an application process
>>>> its
>>>> rank when launched.
>>>> Note that it disappears in I wouldn't recommend looking for it.
>>>> Is
>>>> there something you are trying to do with it?
>>> Recently on this list I recommended somebody use it for their needs.
>> Ah - yeah, that one slid by me. I'll address it directly.
> I was quite surprised that openmpi didn't have a command option for this
> actually, it's quite a common thing to use.

Nobody asked... ;-)

>>>> Reason I ask: some folks wanted to know things like the MPI rank prior to
>>>> calling MPI_Init, so we added a few MPI envar's that are available from
>>>> beginning of process execution, if that is what you are looking for.
>>> It's also essential for Valgrind support which can use it to name
>>> logfiles according to rank using the --log-file=valgrind.out.%
>>> q{OMPI_MCA_ns_nds_vpid} option.
>> Well, it won't hurt for now - but it won't work with 1.3 or beyond. It's
>> always risky to depend upon a code's internal variables as developers feel
>> free to change those as circumstances dictate since users aren't supposed to
>> be affected.
>> I believe this is partly what motivated the creation of the MPI envars - to
>> create a vehicle that -would- be guaranteed stable for just these purposes.
>> The concern was that users were doing things that accessed internal envars
>> which we changed from version to version. The new envars will remain fixed.
> Absolutely, these are useful time and time again so should be part of
> the API and hence stable. Care to mention what they are and I'll add it
> to my note as something to change when upgrading to 1.3 (we are looking
> at testing a snapshot in the near future).


OMPI_COMM_WORLD_SIZE #procs in the job
OMPI_COMM_WORLD_LOCAL_SIZE #procs in this job that are sharing the node
OMPI_UNIVERSE_SIZE total #slots allocated to this user
                                (across all nodes)
OMPI_COMM_WORLD_LOCAL_RANK local rank on node - lowest rank'd proc on
                                the node is given local_rank=0

If there are others that would be useful, now is definitely the time to
speak up!

> Ashley Pittman.
> _______________________________________________
> users mailing list
> users_at_[hidden]