dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Mar 22, 2011 at 07:26:11PM +0000, Garth N. Wells wrote:
>
>
> On 22/03/11 19:13, Anders Logg wrote:
> > On Tue, Mar 22, 2011 at 06:29:23PM +0000, Garth N. Wells wrote:
> >> Our 'automatic' initialisation of MPI and PETSc is a real mess at the
> >> moment. It seemed to work before by good luck. The major issue is
> >> controlling order in the singleton class SubSystemsManager. For example,
> >> I see that the function SubSystemsManager::init_mpi is called, which set
> >> variables to take responsibility of MPI, and *after* this the
> >> SubSystemsManager constructor is called, which resets that flags. The
> >> end result is that MPI is not finalized.
> >>
> >> I don't see an option other robust option than explicit 'initialise'
> >> (and maybe 'finalise') function calls. Any other suggestions?
> >
> > I think it should be possible to control the order.
>
> Unfortunately that's not straightforward. There's a lot on the web about
> it. One approach is to use a static pointer and create the object
> dynamically, but this then requires an explicit call to destroy the
> object. I've looked at this a lot.
>
> > I would very much
> > like to avoid explicit init functions.
> >
>
> Ultimately, I think that this will be unavoidable. Explicit calls are
> good because its crucial to control the destruction when 'systems' (like
> MPI) are running in the background.
>
> > Can you create a simple test that goes wrong and maybe I can look at
> > it (but not tonight).
> >
>
> Just run anything in parallel (-np 1 is enough). Put a write statement
> in SubSystemsManager::init_mpi and SubSystemsManager::SubSystemsManager.
>
> Feel free to try sorting it out. It needs to be fixed quickly, since
> we're broken in parallel.

What caused it to break? It worked before.

--
Anders