From: Jing Guo <guo@dao.gsfc.nasa.gov>
Newsgroups: comp.parallel.mpi
Subject: Re: Environment variables under MPI()?
Date: Mon, 24 Aug 1998 12:48:10 -0400
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-Id: <35E1994A.794B@dao.gsfc.nasa.gov>
References: <35DE20E3.2781@dao.gsfc.nasa.gov> <6rldba$mlf@news1.newsguy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Greg Lindahl wrote:
> 
> Jing Guo <guo@dao.gsfc.nasa.gov> writes:
> 
> > > Sure: write your own small piece of code to pass these variables
> > > around at the start of your run.
> >
> > It is the most frequent suggestion I heard before, but I didn't like it:
> >
> >   a) It won't work if the implementation does not even have the
> >     _right_ values for the root processor.  (Yes, such implementation
> >     does exist.)  I assume you were also talking about values defined
> >     _externally_, not _internally_ by a program.
> 
> It is easy to write a program to write the Unix environment into a
> file, and then have your MPI root program read this file and send its
> contents to all the other nodes.

Hold the thought, I will argue against it later.

> 
> >   b) It might not be portable.  Since it is really an OS interface
> >     issue, it should not be determined unilaterary by a software
> >     developer.
> 
> It's a lot more portable than complaining that MPI implementations
> should propagate the Unix environment!

Sorry if I gave you that impression.  I just wondered that maybe the 
MPI community already have a good understanding on this issue.  It 
does not mean that I think "MPI implementations should propagate the
Unix environment".  Although it might be _a_ good solution.  I will 
take anything portable, including the solution you suggested in ealier 
for a), with some reservations.

> 
> >   c) Thinking you are given a communicator and expected to develop a
> >     library working in that given world, I wonder my own small piece
> >     of code will ever work under that situation.
> 
> It is not a surprise that a library should need initialization in
> order to run. It _is_ a surprise that you think the Unix environment
> is the right place to put it. 

I have to argue that using Unix environment may be the _only_ elegant 
and portable way to have a handle on per-run user-configurable 
parameters for a software development system.  Just consider the 
example you made earlier for my comment a):

  ... have your MPI root program read this file and ...

Do you want to have a _filename_ hardwired into the code, or make it
user-configurable?  In the latter case, there must be a way to pass
that filename to the library initialization procedure, right?  

Of course, one may choose to use **argv to handle this variable. 
What about Fortran programs?  

Or using stdin, then we bring in a much more complicated issue.  Is
it a good idea to reserve stdin for this purpose only?

Regarding that a library should need initialized in order to run,  I
think it is mainly a design issue.  It might hard to argue which design
is better, but it certainly would limited the choices of the designs 
to consider only initializing on the top. 

> [...] Given that the MPI standard doesn't even
> really address access to conventional Fortran files, I think you are
> expecting too much of the standard.

Hold your horses, I don't think I am complaining the standard.  Oh 
well, if you have to take that way, there is nothing I can do about 
it :-).

It might be expecting too much of the standard.  However, I would 
like people to treat this as an implementation quality issue, since 
to design and to develop an application development system, one has 
to face this problem as a requirement issue.

Best regards!

Jing
> 
> -- g

-- 
________________________________ _-__-_-_ _-___---
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