On Wed, Mar 11, 2009 at 12:52 PM, Tim Kroeger <tim.kroe...@cevis.uni-bremen.de> wrote: > 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
Hmm... the biggest difference with the TransientLinearImplicitSystem would probably be the "old_local_solution" and "older_local_solution" vectors... I'm guessing you guys have already investigated those though? -- John ------------------------------------------------------------------------------ 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
