How are you writing out the solution? This certainly doesn't happen when using Exodus (Hilbert keys aren't involved there at all).
Derek On Wed, Aug 12, 2015 at 1:45 PM David Knezevic <david.kneze...@akselos.com> wrote: > On Wed, Aug 12, 2015 at 1:32 PM, John Peterson <jwpeter...@gmail.com> > wrote: > > > Sorry it has taken a while for me to respond, was on vacation... > > > > > No worries at all! > > > > > On Fri, Aug 7, 2015 at 9:13 AM, David Knezevic < > david.kneze...@akselos.com > > > wrote: > > > >> This is an issue that has been raised on the list before: libMesh writes > >> out solutions to disk using an indexing scheme based on a Hilbert curve, > >> in > >> order to provide a partition independent numbering. As far as I > >> understand, > >> this uses the locations of nodes to generate the numbering and as a > result > >> it produces incorrect results on a "slit" mesh. > >> > > > > It produces something, though, right, it's just that the element > numbering > > is indeterminate? Or does it crash? > > > > It produces a "mixed up" solution, i.e. values on either side of the slit > are mixed up in a random way. This is a bit nasty because you aren't > necessarily aware that there is a problem unless you look closely, hence my > question below about an error checker for this. > > > > > I believe the only fix for this is to introduce a small gap in the mesh > so > >> that we don't have any coincident nodes, is that right? I was wondering > if > >> anyone can provide guidance about how big that gap has to be? Is a > machine > >> precision gap sufficient, or does it have to be significantly larger? > >> (I've > >> generally used a gap of 1.e-5 which works fine, but I was wondering what > >> the tolerance for the Hilbert indexing is, and if it can be changed.) > >> > > > > I've played around a bit with the Hilbert Keys stuff, particularly with > > converting from floating point values to Hilbert keys and back to > floating > > point values. From what I vaguely recall, not only was the round-trip > not > > bitwise-accurate, it actually wasn't even close in some cases. I can > > probably dig up some actual numbers if you are interested. I don't know > > exactly what this means for your gap width stuff, other than that it > might > > work only erratically. > > > > hmm, well it sounds like that implies that an epsilon separation is > sufficient to avoid a Hilbert Key clash. > > > > > Another question: It would be helpful if we could trigger an error if a > >> slit mesh is detected when writing out or reading in, since otherwise we > >> can get "silent failures". Would this error detection be feasible? I'd > be > >> happy to work on it, if there is a clear path on how it could be > >> implemented. > >> > > > > Only thing that comes to mind is writing a separate function that loops > > over the elements, computes their Hilbert Keys, and reports any > > collisions. It might only be feasible to do that after the Mesh has been > > read in though... > > > > This sounds good to me, actually. I'd like to be able to call a function > that checks for Hilbert Key collisions. > > I'd be happy to work on this and put it into a PR. Any chance you can point > to any Hilbert Key code that I can refer to in order to help get started? > > Thanks, > Dave > > ------------------------------------------------------------------------------ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
