On Sun, 20 May 2012, Kirk, Benjamin (JSC-EG311) wrote: > I like (C) but agree it might be tricker to get right and worry > about some corner cases.
Agreed. Plus (C) won't work unless we either give up on canonical ordering entirely (which I don't like - space filling curves are a nice start toward doing N-to-M restarts without making a hash of the initial partitioning) or pick a more robust ordering like (A) or (B) to do the renumbering on output. > I haven't had a chance to reproduce the issue, but I wonder if we > could reproduce this with two coordinates and libHilbert directly > with 32bit ints? Then submit it to Chris and see if he has any > suggestions. Looks doable: old source = (x,y,z)=(0.00325521, 0, 0) icoords[0] = 13981013 icoords[1] = 0 icoords[2] = 0 new source = (x,y,z)=(0.00358073, 0, 0) icoords[0] = 15379114 icoords[1] = 0 icoords[2] = 0 Both give 46_3267296239_3204181950 as the hilbert indices. > So is this just an unlucky coincidence or a bug in the hilbert code? I haven't yet tried (13981013,0,0) vs (15379114,0,0) in a standalone test, but yeah, it looks like it might be a libHilbert bug. Even if it is a bug, that's worth reporting upstream but we wouldn't want to actually fix the bug until we've got plan (C) in place, so we don't lose compatibility with old solutions. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
