On Fri, Feb 15, 2013 at 2:43 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@nasa.gov> wrote:
On Feb 15, 2013, at 3:30 PM, John Peterson <peterson@cfdlab.ae.utexas.edu> wrote:
> I'd say --disable-mpi should allow a PETSc with an mpiuni implementation (if such a beast still exists) but not allow a PETSc that has a "real" MPI implementation.  No idea how we'd detect that though :P

What we had before was, if the PETSc configure failed fallback to looking specifically for MPI, the assumption being if you wanted PETSc certainly you want MPI.

What Roy didn't like was, if you don't ask for MPI, don't even bother with PETSc.

What we have now is,  if the PETSc configure failed do the MPI fallback unless --disable-mpi is passed.


That should work, which overcomes my objection that LIBMESH_HAVE_MPI should not get defined when --disable-mpi is passed.  So long as that is true, I'm not sure I care *how* PETSc is doing its own MPI thing...

Yeah, as long as it compiles.  If !LIBMESH_HAVE_MPI, libMesh::COMM_WORLD is an int, right?

int                COMM_WORLD = 0;

does code like this

ierr = VecCreateGhost (libMesh::COMM_WORLD, petsc_n_local, petsc_n,
petsc_n_ghost, petsc_ghost,

ierr = MatCreate(libMesh::COMM_WORLD, &_mat);

still compile?