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
