On Mon, 2 Jun 2008, Martin Luethi wrote:
> Benjamin Kirk writes: > > > Making the "bins" larger would just make the problem less likely to > > > trigger. Using our old keys (based on pointer values) would fail on > > > a ParallelMesh. Searching all neighboring bin keys would make > > > LocationMap::find() take 3^d times longer, but that's the best fix I > > > can think of. Anyone else have any suggestions before I get to it? On second glance, it might not be so bad. I've written the code to check the central bin key before looking at any adjacent keys, which means it'll only take 27 times longer 0.001% (or whatever) of the time. It's a simple fix that works for David's code and the examples, so I'll commit it to SVN in a few minutes. But it still feels like we ought to have a better way to find duplicate points. > Why wouldn't two nodes at the same coordinates have the same float > representation? Because they've been created in two different ways, from two different element refinements, and (for second-order geometric elements, at least) this occasionally adds floating point error. > The only alternative I see is to round to a certain number of > digits (I guess that is what you call "increase bin size"). Right. The trouble is that no matter how many digits you truncate, there's still always going to be some situations where you round x down and round x+epsilon up. --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
