← Back to team overview

dolfin team mailing list archive

Re: manager classes

 



Anders Logg wrote:
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?


Unfortunately not.

The problem is that MPIManager might finalize MPI before PETSc has been finalised. If MPI is initialised before PETSc, then PETSc should be finalised before MPI is finalised. The problem is that we have no control over the order in which MPIManager and PETScManager are destroyed.

I'm thinking of a singleton class DolfinManager which is responsible for the creation and destruction of various managers in the appropriate order.

Garth



Follow ups

References