Sorry it has taken a while for me to respond, was on vacation... 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? 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. > 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... -- John ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
