On Wed, 11 Mar 2009, Roy Stogner wrote: > On Wed, 11 Mar 2009, Tim Kroeger wrote: > >> It happens in System::project_vector() for the case of a ghosted vector. >> This calls DofMap::enforce_constraints_exactly(), which in line 680 of >> dof_map_constraints.C calls NumericVector::operator(). It hits the >> libmesh_assert() near the end of PetscVector::map_global_to_local_index(), >> i.e. the index supplied to operator() is neither a local nor a ghost index. > > Hmm... The index is pulled from a constraint-equation-expanded > local_dof_indices. The in-element local indices should certainly be > local or ghost indices, but is it possible that we're not inserting > constraint equation dependencies into DofMap::_send_list? That would > explain why the problem is so hard to replicate - it would be common, > even when doing a lot of adaptation, for all nonlocal constraint > equation dependencies to end up getting in the send_list anyway when > the DofMap finds them in immediately neighboring elements.
Still, I wonder why it cannot be replicated by writing the grid to a file and re-reading it in. Will that change the distribution of the dofs to the processors? >> There are 7 systems in the application (all on the same grid). Two >> ExplicitSystem's and two LinearImplicitSystem's are projected successfully, >> but the first TransientLinearImplicitSystem triggers the crash, when >> projecting its _transient_old_local_solution. That system contains two >> variables, both of the same FE-type. > > Could you list the variables and FE types in each of the systems? One > problem with my theory above (other than that I'll have to pore > through all of dof_map*.C to check it...) is that I'd have expected > the crash to occur earlier. All variables are first order Lagrange. Hence, the systems differ only in the system type and the number of variables: No. Type #Vars ----------------------------------------- 0 ExplicitSystem 5 1 LinearImplicitSystem 1 2 LinearImplicitSystem 1 3 ExplicitSystem 1 4 TransientLinearImplicitSystem 2 5 TransientLinearImplicitSystem 2 6 TransientLinearImplicitSystem 1 As said before, the crash is triggered by system 4. I would suspect that it only occurs on transient system -- although this surprises me since the other systems contain ghosted vectors as well, don't they? Another possibility is that it is triggered by vectors that contain more than one variable -- but then again, it should at least be triggered by system 0 as well. >> Do you have any idea how to track this down further? > > Well, there's the hard way: Compile the crashing test case in devel > mode You mean debug mode, right? > and run with -start_in_debugger (this will be easier if you can > replicate the problem on fewer than 8 CPUs). Then pore through the > data structures at the crash by hand to find out what DofObject the > bad index is coming from. > > But let's try the either-easy-or-futile way first: I'll write a > (possibly redundant) patch to make sure we're properly getting > constraint dependency dofs into the send list, and you can try running > with that. We can at least verify or rule out my first guess before > we need more information to come up with a second guess. I vote for this easy way and wait for your patch. (-: Nevertheless, I'll try out whether the crash occurs on 2 CPUs as well. Best Regards, Tim -- Dr. Tim Kroeger tim.kroe...@mevis.fraunhofer.de Phone +49-421-218-7710 tim.kroe...@cevis.uni-bremen.de Fax +49-421-218-4236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
