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. 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... -Ben ------------------------------------------------------------------------------ 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
