Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r31302 - in trunk: opal/mca/base orte/tools/orterun
From: Kenneth A. Lloyd (kenneth.lloyd_at_[hidden])
Date: 2014-04-03 12:27:12

Would you consider a user-defined process language library outside of
OpenMPI? Process functors could be defined by compositions in this external
area, and maintenance of the language simply the user's responsibility?

-----Original Message-----
From: devel [mailto:devel-bounces_at_[hidden]] On Behalf Of Ralph Castain
Sent: Thursday, April 03, 2014 8:17 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r31302 - in trunk:
opal/mca/base orte/tools/orterun

I can see the potential utility, but I do have concerns about how to make it
work without causing a lot of user problems:

* as currently implemented, it only affects procs launched via mpirun. This
seems odd - if the user does a direct launch, they would get totally
different behavior? Shouldn't the registering and parsing of this MCA param
follow our usual procedure and be done by the application itself instead of
by orterun?

* Imagine someone has entered this MCA param into the default MCA param
file, and that it includes "foo=car" in it. Now the user sets "foo=baz" in
their environment. How many hours will the user spend tearing out his/her
hair trying to understand why the application behavior isn't as expected
before they finally realize that the default MCA param file is messing with
their non-OMPI envars? Once they finally do figure it out, how do they
"zero" that MCA param so it isn't processed? We don't have a mechanism for
overriding a value with "NULL" - doesn't this option require one?

* again, someone puts an entry in the default MCA param file that includes
"foo=car". The user executes mpirun with "-x foo=baz", which is perfectly
legitimate. What is the precedence rule we use to determine the value of
foo? If we consolidate the two options (as you suggest), then this would be
alleviated - but one is an MCA param and the other a non-MCA cmd-line
option, so we would have to break backward compatibility to resolve it
(which isn't impossible - just worth a discussion).

* assume an entry in the MCA param file that includes multiple envars, one
of which is "foo=car". If the user then puts "-mca env_list foo=baz" on
their cmd line, do we delete all the other envars in the original entry and
only do the new one? Or would someone expect that only the new one would be
modified or added, but the others would remain?

Hence I think this requires some discussion at next week's call. Remember,
by policy, we don't forward non-MCA envars - but now we are forcibly setting
them only in the app procs. Strikes me as a major change in behavior, and
I'm not sure it won't cause more trouble than it solves.

On Apr 3, 2014, at 1:01 AM, Shamis, Pavel <shamisp_at_[hidden]> wrote:

>> mca param file treats any key=val as mca parameter only.
>> In order to add parser support for something that is not mca param, will
require change file syntax and it will look bad, i.e.:
>> mca btl = sm,self,openib
>> env DISPLAY = console:0
>> I think the current implementation is less intrusive and re-uses existing
infra in the most elegant way.
>> The param file syntax change is too big effort to justify this feature
(IMHO) which can be provided with existing infra w/o breaking anything.
> IMHO this is a useful parameter option to have. If we may consolidate
> these two parameters (-x and the new one) into single one, it might be
even more helpful.
> Best,
> Pasha.
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription:
> Link to this post:

devel mailing list
Link to this post:

No virus found in this message.
Checked by AVG -
Version: 2014.0.4355 / Virus Database: 3722/7293 - Release Date: 04/03/14