Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Brian W. Barrett (brbarret_at_[hidden])
Date: 2007-11-05 17:32:04


On Mon, 5 Nov 2007, Torsten Hoefler wrote:

> On Mon, Nov 05, 2007 at 04:57:19PM -0500, Brian W. Barrett wrote:
>> This is extremely tricky to do. How do you know which environment
>> variables to forward (foo in this case) and which not to (hostname).
>> SLURM has a better chance, since it's linux only and generally only run on
>> tightly controlled clusters. But there's a whole variety of things that
>> shouldn't be forwarded and that list differs from OS to OS.
>>
>> I believe we toyed around with the "right thing" in LAM and early on with
>> OPen MPI and decided that it was too hard to meet expected behavior.
> Some applications rely on this (I know at least two right away, Gamess
> and Abinit) and they work without problems with Lam/Mpich{1,2} but not
> with Open MPI. I am *not* arguing that those applications are correct (I
> agree that this way of passing arguments is ugly, but it's done).
>
> I know it's not defined in the standard but I think it's a nice
> convenient functionality. E.g., setting the LD_LIBRARY_PATH to find
> libmpi.so in the .bashrc is also a pain if you have multiple (Open) MPIs
> installed.

LAM does not automatically propogate environment variables -- it's
behavior is almost *exactly* like Open MPI's. There might be a situation
where the environment is not quite so scrubbed if a process is started on
the same node mpirun is executed on, but it's only appearances -- in
reality, that's the environment that was alive when lamboot was executed.

With both LAM and Open MPI, there is the -x option to propogate a list of
environment variables, but that's about it. Neither will push
LD_LIBRARY_PATH by default (and there are many good reasons for that,
particularly in heterogeneous situations).

Brian