That would definitely be helpful. Send it to the list but to Roy and me directly too. I will be traveling a lot for a few days so I am not sure when I can get to it, but I would like to help make sure you get going...
-Ben On Jun 19, 2013, at 5:46 PM, "ng a Bhatia" <[email protected]> wrote: > Hi, > > If this is helpful, I prepared a small example that mimics what I am > trying to do, and trips the same exception. > > Any insight would be appreciated. > > Thanks, > Manav > > > > On Wed, Jun 19, 2013 at 9:28 AM, Manav Bhatia <[email protected]> wrote: > >> 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 ------------------------------------------------------------------------------ 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
