From: Jing Guo <guo@dao.gsfc.nasa.gov>
Newsgroups: comp.parallel.mpi
Subject: Re: Environment variables under MPI()?
Date: Mon, 24 Aug 1998 13:55:34 -0400
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-Id: <35E1A916.15FB@dao.gsfc.nasa.gov>
References: <35DDC41C.167E@dao.gsfc.nasa.gov> <6rnka3$m69@tbag.rsn.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Raja Daoud wrote:
> 
> Jing, let's split the env var issue into two parts:
> 
> 1- using getenv() for initialization before MPI_Init()
> 
> 2- doing initialization after MPI_Init()
> 
> For #1, the bigger issue is the lack of a standard behavior for code
> that precedes MPI_Init().  It could be executed a different # of times
> depending on the implementation (typically either 1 or N times, in some
> cases N+1 times).  For this reason, users are discouraged from having
> meaningful code before MPI_Init().  A safer solution is to map it to
> case #2.
> 
> For #2, MPI can be used to help in the initialization, broadcasting the
> data from some "root" process that can somehow be selected.  Here it's
> an issue of which of the functionalities not mandated by the MPI std do
> you want to rely on, and have more confidence in its portability:
> 
> a- Use the environment of a root process, assume that it is inherited
>    from the user's environment.
> 
> b- Get the info from the command line, assuming that at least a root
>    process gets the correct argc/argv set by MPI_Init().
> 
> c- Store the info in a file and assume that it is accessible from a root
>    process.
> 
> d- Assume that at least a root process can read stdin.
> 
> etc.  I would guess that 'b' is the most portable solution.  'c' may be
> as portable, but has the added hassle of managing an extra file.  If the
> filename isn't hardcoded, then you're passing it via the command line
> and assuming 'b' as well, or via the 'a' or 'd' mechanisms.  I think 'd'
> is the least portable.

Yes!  This is certainly a sigh of well understanding the issue.  

My only comments are:

  o "b" is a less portable solution for Fortran programs, than "a".
 
  o both "a" and "b" require inquiring variables of known names on the 
    top (where the "root" makes sense) by all modules that require some 
    variables, a situation would limit the underline desigh choices.

    I would prefer to write a module that get and populate _all_ 
    "environment vairables" (defined by any chosen means) _after_ 
    MPIinit(), with another interface to get the value of a given
    variable name.  It would solve the problem once for all.

    The only problem of applying the approach to "a" is that I don't 
    think there is a way to getALLenv().  So much for a good 
    design :-).  

>
> Regards,
> 
> --Raja
> 
> [plug:  in HP MPI, the user can set optional lists of VAR=VALUE tuples
> for the processes (per host/binary/#copies combination) to be visible
> before MPI_Init().  Example:
> 
> -h host1 -np 16 -e FOO=foo -e BAR=bar  a.out [args....]
> -h host2 -np 16 -e FOO=toto -e BAR=lala  b.out [args....]
> 
> BTW, HP MPI uses rsh (remsh) to start remote processes.]

It seems to be a good enough solution!  I just wish all Unix based
system venders could come to a consense on their approaches for the
issue.  It would make our MPI software development life much easier.  

Jing 

> 
> -=-
> Raja Daoud                              Hewlett-Packard Co.
> raja@rsn.hp.com                         http://www.hp.com/go/mpi

-- 
________________________________ _-__-_-_ _-___---
Jing Guo, guo@dao.gsfc.nasa.gov, (301)805-8333(o), (301)805-7960(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771