Message-Id: <4.2.0.58.19990801145930.00c7c1e0@localhost>
Date: Sun, 01 Aug 1999 15:13:04 -0500
To: Jeff Squyres <jsquyres@lsc.nd.edu>
From: William Gropp <gropp@mcs.anl.gov>
Subject: Re: MPI-2 MPI_Comm_spawn inconsistency 
Cc: mpi-core@mcs.anl.gov
In-Reply-To: <Pine.SOL.4.10.9907301821360.1624-100000@athos.lsc.nd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpi-core@mcs.anl.gov
Precedence: bulk

At 06:26 PM 7/30/99 -0500, Jeff Squyres wrote:
I think we came across a conflict in the MPI-2 standard today (gasp!).

In looking at MPI_Comm_spawn[_multiple] the other day, we noticed that one
of the parameters doesn't seem to make sense for non-root ranks.  Let me
refresh your memory of MPI_Comm_spawn (MC_Spawn_multiple is similar, so
we'll just use MC_spawn here):

MPI_Comm_spawn(IN command, IN argv, IN maxprocs, IN info, IN root, IN
               comm, OUT intercomm, OUT array_of_errorcodes)

command, argv, maxprocs, and info are specifically denoted as "significant
only at root".

After calling MPI_Comm_spawn (which is collective across comm), everyone
gets a new intercomm to communicate with the spawned children.  Everyone
is also supposed to also get an array of errorcodes that represent the
return codes from spawning each of the maxprocs children.

MPI-2 88:13 specifically says, "The array_of_errorcodes is an array of
length maxprocs..."  But maxprocs is only significant at the root -- so
the non-root members of comm may not know what maxprocs is.  Hence, they
might not know how long array_of_errorcodes is supposed to be.  Recall
that in true MPI fashion, the user is responsible for allocating
array_of_errorcodes; this can be pretty hard to do if you don't know how
long it needs to be.

So this doesn't seem to make sense.

Significant at the root only means that that argument is ignored except by the designated root process (in order to avoid confusion over which value to use if different processes provided different values).  We can still require that the arrays representing other arguments have the appropriate sizes.

Bill