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
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
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:
> 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
--
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
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
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
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:
> 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
