On Tue, Mar 22, 2011 at 09:21:38PM +0000, Garth N. Wells wrote: > > > 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)
ok. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
