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 Stogne
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
Finally getting around to working on this... but it's actually much more
complicated than I thought.
My idea was to simply use something like:
counter + (std::numeric_limits::max() / n_processors())
* processor_id()
as the unique ID. Where "counter" is increased every time a DofObject gets
crea
On Wed, 10 Jul 2013, Derek Gaston wrote:
> On Jul 10, 2013, at 11:05 PM, Roy Stogner wrote:
>
>> I'd rather avoid adding a mandatory extra 8 bytes to every DofObject,
>> but I don't see any insuperable obstacle to adding an optional 8
>> bytes; this could even be run-time optional since we alrea
Sent from my iPad
On Jul 10, 2013, at 11:05 PM, Roy Stogner wrote:
> Or does this need to work in the moving mesh case too?
Yep, moving mesh... and in fact I need it to give the exact same
numbering to two meshes, where one is simply a distortion of the other
one (element IDs currently do this
On Wed, 10 Jul 2013, Derek Gaston wrote:
> Wait - I see what you're asking...
In that case you're one step ahead of me. ;-) I'm mostly just trying
to see if I understand your problem and your proposal.
But I am also trying to see if there are less intrusive ways to manage
the same effect. I
Wait - I see what you're asking... how are we going to use this to index
our data? Well, we already use "id" to index into rather large maps (yes,
regular std::map) to get at this data and we haven't seen that showing up
in our timing so I'm not super worried about it.
If the sparsity of it c
Sent from my iPad
On Jul 10, 2013, at 9:50 PM, Roy Stogner wrote:
> That'll get real sparse real fast, then. You're planning to use this
> as the index to map or unordered_map?
Yep, super sparse... So some some sort of hash map (probably
unordered_map) of unique_id->object (but could be unique
On Wed, 10 Jul 2013, Derek Gaston wrote:
> The new object will have a new ID. No attempt made a resurrecting old
> ids. New object means new ID...
That'll get real sparse real fast, then. You're planning to use this
as the index to map or unordered_map?
---
Roy
--
The new object will have a new ID. No attempt made a resurrecting old
ids. New object means new ID...
Derek
Sent from my iPad
On Jul 10, 2013, at 4:49 PM, Roy Stogner wrote:
>
> On Wed, 10 Jul 2013, Derek Gaston wrote:
>
>> I am thinking that we need a globally unique identifier for all dof
On Wed, 10 Jul 2013, Derek Gaston wrote:
I am thinking that we need a globally unique identifier for all dof
objects. This would be a serially increasing number that would be
attached to the dof object. When a dof object gets sent over the
wire and its "id" is changed... the unique identifier
I think I mentioned this before, but at that point I found a workaround.
But now I'm stuck again...
So - let's say I have a datastructure that is indexed by element id. If
I'm using parallel mesh and adaptivity when the mesh is repartitioned
elements can be sent from one processor to another, ri
12 matches
Mail list logo
