Yes - I am assuming that packed_range stuff communicates this fine...
No - that's not enough.
Because redistribute() is called before processor_id is set for Nodes. So
a decision about what the unique_id for a Node should be can't be made yet.
Derek
On Mon, Aug 5, 2013 at 5:23 PM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> On Mon, 5 Aug 2013, Derek Gaston wrote:
>
> The bad part is that the Nodes _also_ get packed up and sent during
>> redistribute()... which means that if we set the
>> unique_id on the nodes _after_ redistribute() we'll have to go through a
>> second phase of renegotiation to make sure
>> those are consistent across all processors. However, it's not until
>> _after_ redistribute that the processor_id()
>> gets set for nodes! So we can't set the unique_id for nodes before
>> redistribute...
>>
>> Sigh.
>>
>> Am I way off base here?
>>
>
> We need to make sure that the packed_range stuff communicates
> unique_id just to prevent repartitioning from breaking it in
> ParallelMesh. And once that works, won't redistribute() work fine
> too?
>
> Crossing fingers,
> ---
> Roy
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
