As an additional piece of info, this is being thrown when the method libmesh_assert_valid_parallel_object_ids is being called for the nodes.
I am wondering if this assert for my case needs to be true. Since I have partitioned elements, some nodes will be duplicated between processors. So, the min_procid for a node can be different from the proc_id. Any thoughts? Manav On Wed, Jun 19, 2013 at 9:07 AM, Manav Bhatia <[email protected]> wrote: > Hi Roy, > > I followed the procedure as discussed earlier to initialize > ParallelMesh. Elements are partitioned and all relevant nodes are added to > each processor with the ids of the elements and nodes set before addition. > > I am tripping the assert on line 771 of parallel_mesh.C: > > libmesh_assert ( !obj || procid == min_procid ); > > It is likely that I have a bug in my initialization, but I wanted to > see if you had any quick thoughts on this error. > > Thanks, > Manav > > On Thu, Jun 6, 2013 at 3:18 PM, Roy Stogner <[email protected]>wrote: > >> >> On Thu, 6 Jun 2013, Manav Bhatia wrote: >> >> I am curious if there is an advisable strategy to add nodes and >>> elements to the ParallelMesh? >>> >> >> Usually what we do in mesh refinement is give each processor >> "ownership" of dof ids which are equal to the processor id modulo >> n_processors+1. That way, no overlap. >> >> >> If an initial approximate mesh partition is available from a >>> space-filling algorithm, then is it OK to add the partitioned nodes to >>> the >>> ParallelMesh on its respective processor? Following this, how does one >>> add >>> the elements? Is it safe to add all elements that a node on a processor >>> connects to? If so, what does one do about nodes that the element might >>> be >>> connected to, but are not stored on the processors? >>> >>> On the other hand, is it better to have an initial partition of >>> elements (as opposed to nodes), and then one can add elements and only >>> relevant nodes to the ParallelMesh on a specific processor? >>> >> >> Since libMesh defines node processor ids in terms of the connected >> element processor ids, it's better to partition the elements and then >> derive the node partitioning from that. If you do that and you make >> sure the interfacial nodes got added consistently on both processors, >> then MeshCommunication::gather_**neighboring_elements() should get you >> the ghost objects. >> >> >> In either case, if I am assigining consistent IDs to the nodes and >>> elements before adding to ParallelMesh, would this be enough to ensure >>> consistency of node and element data? >>> >> >> I believe so, yes. You'll want to do a renumbering afterwards for >> efficiency, though. >> --- >> Roy >> > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
