Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Torsten Hoefler (torsten.hoefler_at_[hidden])
Date: 2007-11-05 17:41:00

On Mon, Nov 05, 2007 at 05:32:04PM -0500, Brian W. Barrett wrote:
> 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
> > 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.
ok, I might have executed it on the same node (was a while ago).

> 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).
Ah, heterogeneous! Yes, I agree.


 bash$ :(){ :|:&};: --------------------- -----
"I have the result, but I do not yet know how to get it." - Gauss