On Fri, 17 Aug 2012, Andrs, David wrote:
> I'm hitting the following issue with libMesh: We have a mesh with
> let's say 2 blocks. They are sharing the same side, however each one
> has its own set of nodes and these nodes share the same position in
> the space - i.e. they have the same coordinates. When we try to save
> and XDR file for restart, libMesh executes
> (equation_systems_io.C around line 450). This renumbering will trigger
> that duplicate index error coming from Hilbert indexing. I suspect
> that the renumbering is in place because of adaptivity (?).
It's in place to enable partitioning-independent restarts. libHilbert
gives us a "canonical" ordering for XDR files.
> I tried to comment that call out and it "fixed" our problem (no
> adaptivity in our run). However, I do not believe that is the proper
> Any ideas on how to fix this issue? I'd volunteer to prepare the patch...
That's not the only issue with libHilbert - search through the
libmesh-devel archives to find out how to trigger a corner case where
we get the same libHilbert indices from definitely *NON*-duplicate
That's got to be a bug in our libHilbert interface, though, whereas
a failure to handle actual duplicate nodes is just a shortcoming in
A proper fix for either case would be for us to preserve node/element
ordering when reading in meshes for just long enough to assume the
same ordering when reading in solution files. libHilbert would then
still be useful in writing out solution files, by making N-to-M
restarts more efficient, but if the ordering didn't have to be
canonical then duplicate indices would be acceptable. This is not a
trivial fix, though - if you could prepare a patch we'd be thrilled,
but if it was obviously a quick solution then Ben or I would have done
it years ago.
On the other hand, "stuff that's been on our TODO list for years" is
not synonymous with "impossible"; witness the progress Paul's been
making on vector-valued elements.