On Fri, Jan 04, 2008 at 10:25:35AM -0600, Matthew Knepley wrote:
On Jan 4, 2008 10:22 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
We have a problem at the moment when using PETSc related to conflicts
between dolfin::MPIManager and dolfin::PETScManger as to who should
initialise and finalise MPI. The difficulty is that we can't control the
order in which MPIManager and PETScManager are destroyed.
Given that we will probably have more 'manager' classes in the future
(e.g. for Trilinos), what is the best approach? Some possibilities are
one 'Manager' class that does the lot, or a SingletonManager which can
control the order in which singleton manager classes are destroyed. Ideas?
When using multiple packages with MPI, you should always have a single MPI
manage class. If MPI is already initialized when PETSc is initialized,
it won't mess
with MPI (and won't finalize it either).
Matt
Good, if it's always the case that PETSc does not finalize when it has
not initialized, then maybe we just need to do the same?
As we have implemented it, MPIManager checks if someone else (maybe
PETSc, maybe someone else) has already initialized MPI and in that
case does not initialize it. Then it should also assume that someone
else will finalize it.
We can just add a bool member initialized_here and then do
if (initialized_here)
MPIManager::finalize();
in the destructor of MPIManager.
Would that help?
