From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Nov 21 11:24:33 2002
Subject: Re: Patching Octave-MPI
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: andyj at splash dot princeton dot edu
Cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Thu, 21 Nov 2002 11:24:30 -0600

On 21-Nov-2002, Andy Jacobson <andyj at splash dot princeton dot edu> wrote:

| Alex Verstak raised an interesting point last year: he said that the
| MPI standard requires that MPI_Init() be fed the *original* argv and
| argc.

Yes, I think that's what he claimed.

But after looking at the MPI docs, I think it wants pointers to them,
so it can strip out its special arguments first, modifying the
argv/argc pair which the original application would then use.  The
argument I remember seeing (from Alex?) was that there is no standard
for the argument names, so the application could not know which args
to avoid.  But I think this is a weak argument, because as Paul points
out, you could mark them specially.  So unless there is some *other*
reason that the MPI_Init function needs pointers to the actual
argv/argc of the main program (say, to get an idea of where the stack
starts for GC or something -- another bad idea, I think!) then I don't
see any reason that you couldn't just fake your own argv/argc for MPI.

There is also a statement in the MPI docs that I saw saying something
about being sure to initialize MPI before doing much of anything (I
think I/O and opening files were mentioned).  Does anyone know the
rationale for that?  What difference would that make?  If it really
does make a difference, then there is another reason to put the call
to MPI_Init in the core Octave.

| It should a pretty trivial matter to determine whether or not the user
| wants a parallel or traditional application when she starts octave.
| Perhaps something as simple as "octave --mpi-server" or "octave
| --mpi-client".  Then we call MPI_Init() (and later MPI_Finalize()) as
| appropriate.  That is just about all that is required from the main
| code; the rest could naturally be moved to .oct.

This is what I was thinking also, that we would

  * Compile support for MPI into Octave based on configure flags (so
    you could omit it completely and still build a working Octave.

  * Even for Octave built with MPI support, only enable MPI
    functionality at run time if Octave is given the appropriate
    command-line option.

jwe