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
