>> Ok, I have found the problem... >> ComputeHilbertKeys is calculating the same node_key for different nodes. >> This is a mess because the mesh has no tears, even for higher h >> refinement levels. >> >> Any idea? I don't know how LibHilbert works. > > I'm afraid this is up to Ben; it's a library he added to help with > parallel I/O, I believe.
Do you have a simple code you can send where I can try to repeat the problem? I am not anticipating duplicate Hilbert keys unless the nodes really are identical to within double precision. Have you seen which nodes are actually producing the identical hilbert keys? This will be the first thing I check. The question is have duplicate nodes appeared from some other reason and the hiblert indexing is just the first thing to detect the error, or if two geometrically distinct nodes really are producing the same hilbert key. In any case I'm certainly interested in the issue and hope to fix it. Thanks. -Ben ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
