Re: [Libmesh-users] Question about unique_ids

[Roy S. <roy...@ic...>]

On Wed, 10 Jan 2018, David Knezevic wrote:

> I'd like to use unique_ids to identify elements and nodes without worrying
> about renumbering, but before I do that I'd like to understand a bit more
> about how unique_ids are defined.
>
> In particular, what is the idea behind how we generate the unique_ids?

Basically we have two constraints:

1. We want to never ever reuse a unique_id for two different
DofObjects of the same category (Nodes, Elems).
2. We want to assign a unique_id to each DofObject as soon as possible.

And that leads us to a few complications:

1. Our unique_id values will often be sparse:  When adaptively
coarsening we delete objects, and we *don't* give their replacements
the same unique_id if/when we adaptively refine the same area again.
When building distributed meshes, we add objects on one processor
without communicating with other processors, so each processor "owns"
an interleaved subset of unique_id space, and may leave some of that
space blank.
2. Our unique_id values are really only well-defined *when* they're
created, and that creation may depend on mesh type and partitioning.
So:

> One concrete question I have is if I create two Mesh objects by reading in
> the same mesh exodus file twice, will those two meshes have matching
> unique_ids? I guess they will simply because "add_node" and "add_elem" will
> be called in the same order during those two read operations.

If both reads are using the same libMesh version, and either both are
to a ReplicatedMesh or both are to a DistributedMesh, then currently
the answer is yes.  I don't expect that to change, though I haven't
really thought about it before.

Please don't count on unique_id numbering remaining the same from
version to version, though!  If you need to open a mesh next year with
the same unique_id numbering it has this year, save that mesh in XDR
or XDA (where we write out unique_id), not Exodus.
---
Roy