dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22198
Re: SubSystemsManager mess
On 22/03/11 21:18, Anders Logg wrote:
> 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.
>
Unpredictable initialisation order of static data. It may have just been
the move of directory. Joachim Haga summed it up well in a code comment:
(google "static initialization order fiasco" for full explanation)
Garth
> --
> Anders
Follow ups
References