On Fri, Feb 15, 2013 at 2:43 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Feb 15, 2013, at 3:30 PM, John Peterson <peter...@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.
>
Understood.
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?
#ifdef LIBMESH_HAVE_MPI
MPI_Comm COMM_WORLD = MPI_COMM_NULL;
#else
int COMM_WORLD = 0;
#endif
does code like this
ierr = VecCreateGhost (libMesh::COMM_WORLD, petsc_n_local, petsc_n,
petsc_n_ghost, petsc_ghost,
&_vec);
ierr = MatCreate(libMesh::COMM_WORLD, &_mat);
still compile?
--
John
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
