On Jan 4, 2008 10:43 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
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).
OK. The problem with what I have now is that MPIManager will initialise
MPI, but might also finalize MPI before PetscFinalize is called. We're
not calling any finalize functions explicitly, rather from the
destructor of the manager class.
Perhaps a good approach is to have a Manager class that creates and
destroys FooManager classes, and is the only class that can create
FooManager classes.
I guess my opinion is that destructors in languages with automatic memory
management are completely unreliable (and the opinion of the PL community).
I would always have an explicit call for any cleanup which has nonlocal results,
e,g, shutdown of MPI library services.
