Actually, let me state this another way.  When looking through all the
logic in parallel_mesh.C, I'm trying to understand under what conditions an
id can change.  These assignments and exchanges are rather complex, so I
didn't want to create a subtle bug...

In add_elem(), add_node(), you mention assigning ids "temporarily" to
ghosted entities.  I thought about doing the same for unique_ids, but then
I thought that it would be more error prone to assign a unique_id even
temporarily and then change it later during the information exchange like
you do for regular ids in renumber_dof_objects().  In my implementation it
is simply not possible to ever change a unique id (at least without a nasty
assertion) once it's been set, guaranteeing uniqueness not matter what.  I
made the arbitrary decision to delay, slightly, the assignment of ids
preferring invalid ids over ids that might change.

That being said, your implementation for ids appears to be working for us
on rather complex simulations meaning that you've most likely managed to
get all of this logic correct so it should be possible to do the same for
unique_ids if we want to follow a similar pattern.  As it stands, this
rather simple unique_id implementation appears to be working great with my
limited testing so far.  I have an object in MOOSE that tests for
uniqueness among all unique_ids in parallel on both serial/parallel meshes
already running and passing.  I'm currently working on a way to verify that
ids are never recycled during coarsening/refinement cycles.

Feedback welcomed.

Cody


On Wed, Oct 16, 2013 at 6:33 AM, permcody . <codypermann@gmail.com> wrote:

> Well I'm open to suggestions but the reason I'm using a setter is because
> I have an assert in the getter.  As the comment says, it's possible to have
> an invalid unique id where this exchange is happening.  On the receiving
> side, I'm asserting that the passed id is either invalid or matches the
> existing id rather than accidentally clobbering anything.  This is simply
> because I didn't put in all the logic to try to assign a unique ids to
> unpartitioned elements.  If you don't like this, I could move your
> "advanced ids up to the top" logic into a subroutine and use that to dish
> out new ids and well as unique ids.
>
> Let me know what you'd like to see.
>
> Cody
>
>
> On Tue, Oct 15, 2013 at 9:44 PM, roystgnr <notifications@github.com>wrote:
>
>> In src/mesh/parallel_mesh.C:
>>
>> > @@ -932,7 +949,9 @@ dof_id_type ParallelMesh::renumber_dof_objects
>> >        {
>> >          requested_ids[obj->processor_id()].push_back(obj->id());
>> >  #ifdef LIBMESH_ENABLE_UNIQUE_ID
>> > -        requested_unique_ids[obj->processor_id()].push_back(obj->unique_id());
>> > +        // It's possible to have an invalid id for dofs not owned by this process.
>> > +        // We'll assert that they match on the receiving end.
>> > +        requested_unique_ids[obj->processor_id()].push_back(obj->set_unique_id());
>>
>> Why are you using the setter here and below?
>>
>> —
>> Reply to this email directly or view it on GitHub<https://github.com/libMesh/libmesh/pull/160/files#r6991733>
>> .
>>
>
>