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