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

[Jed Brown]

Tim Tautges wrote:
> In my experience, using dummy MPI has been confusing.  My experience is
> somewhat limited, since I only encountered it with Zoltan (which uses
> something it calls sMPI, don't know if that's from somewhere else or
> homegrown).
> 
> One of the things that confused me in that case was that I had to
> initialize MPI, even though I had a serial application that wanted to
> use Zoltan serially.  I think the same confusion will exist with MOAB.

Yeah, Zoltan uses siMPI which is apparently a standards compliant serial
implementation.  It does put symbols in the global namespace, but this
is required in order to support PMPI.

> Finally, I don't see why a serial application need call MPI_Init, even
> for MOAB compiled for parallel, if none of the functionality it uses is
> parallel.

It is just there so that MPI_Initialized() returns correct results.
PETSc uses this to determine whether to call MPI_Finalize() when the
user calls PetscFinalize().  This seems circular, but it's important so
that user code does not need to behave differently when running in
serial (doesn't even need to know).

If MOAB does not do any global initialization or cleanup, then you don't
need these functions.

> Looking at MOAB source, if the app doesn't pass any options which
> clearly indicate parallel behavior, none of the MPI stuff ever gets
> called.  We might still need to link to MPI from the serial app, but
> I'm not even sure of that in the static linking case.

The symbols are neede because the number of processors is a *runtime*
option.

> Something in these statements must be wrong, though, if mbconvert was
> failing due to not calling MPI_Init.  Maybe I'll look at that...

The problem here was just calling MPI_Finalize() without calling
MPI_Initialize().

You can't do anything sensible in parallel without being passed a
communicator (it's actually quite bad that MPI_COMM_WORLD is hard-coded
all over moab/parallel, though I don't personally have an application
that requires proper handling of communicators).  In my opinion,
implicit use of MPI_COMM_WORLD is okay when parallel options are given
but the program doesn't pass in a communicator.


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/3426e7ea/attachment.pgp>