[MOAB-dev] [PATCH] Call MPI_Init if using MPI.

[Jed Brown]

Tim Tautges wrote:
> Huh?  MPI_Init needs to be called so that MPI_Initialized returns
> correct results?  So it doesn't return correct results if you haven't
> called MPI_Init?

By correct results, I mean that only one piece of code should actually
think it was resposnible for initializing MPI.  If the MPI_Initialized()
stub always returns 1 (or 0), then different branches will be taken by
some programs when compiled with a real MPI versus a faux MPI.  The
whole point of the a faux MPI is that there is only one version of the
code to maintain, it will behave exactly the same as when built with a
real MPI and told to use a communicator of size 1.

Most users call PetscInitialize() without calling MPI_Init().  Petsc
needs to do global initialization so that various debugging, profiling,
and other features can be runtime options.  If the user has not yet
called MPI_Init(), then PETSc will do it, and also take responsibility
for calling MPI_Finalize(), otherwise it doesn't touch it.  The
semantics regarding MPI_Init is necessarily part of the API, behaving
differently with a faux MPI would change the API, thus causing
superfluous complexity for users (including intermediate libraries).

Note that while PETSc's configure does set PETSC_HAVE_MPI to indicate
whether it is backed by a real MPI, it is *only* set so that users
(intermediate libraries) can determine this, it is *never* used by
PETSc (the name doesn't exist in the repository).


As for Mark's issue, I don't understand why anyone would build PETSc
with no MPI if they were on a system that had a real MPI.  The only
purpose of a faux MPI is to enable users to build without having any
MPI.  There is no performance penalty to using a real MPI and telling
PETSc to just use MPI_COMM_SELF.


It all boils down to the fact that a parallel code is necessarily also a
serial code because it must function correctly on a communicator of size
1.  So if you use a faux MPI for serial builds, correctness is
guaranteed, but if you have separate code paths then you need to
maintain and test multiple versions.


Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20091029/5f468bf9/attachment.pgp>