dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Jan 4, 2008 10:56 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> Matthew Knepley wrote:
> > 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.
> >
>
> Sorry, I should have been a clearer here. We do call the clean-up
> functions explicitly from the destructor. What we don't want is users
> having to call finalize functions.

That was my complaint. The execution of destructors is unreliable in languages
like Python, and thus nothing that has to be reliable (like MPI_Finalize or
PetscFinalize) should ever be called from them (I think).

  Matt

> Garth
>
>
> >   Thanks,
> >
> >     Matt
> >
> >> Garth
>
>
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener