Re: [Libmesh-devel] cached_nodes_still_fit!

[Roy S. <roy...@ic...>]

On Wed, 20 Oct 2010, John Peterson wrote:

> On Wed, Oct 20, 2010 at 4:19 PM, Derek Gaston <der...@in...> wrote:
>>
>> To "fix" this I propose using relative_fuzzy_equals() like so:
>>
>> if (!(elem->point(n) - elem->point(0)).relative_fuzzy_equals((cached_nodes[n] - cached_nodes[0])))
>>
>> But of course this could have the bad side effect of false positives... ie two elements that are _extremely_ similar but not exactly and still pass this check.
>>
>> So what do you guys think?  Is this a valid thing to do... or is it just too unsafe?  Is there a better option?
>
> Good catch.

Very good catch.  I'm somewhat embarrassed that I didn't catch it
myself; After I wrote the code I noticed that my app got way faster
and I verified that the results didn't change but I don't think I
bothered to do any double-checking of how much caching was being done.

> I'll let Roy answer since he wrote that code, but I think what you
> propose doing sounds fine.  You can specify a tolerance to
> relative_fuzzy_equals as well if you want to make it pretty precise.

Precisely.  Using the default tolerance here (I think 1e-6 for
doubles?) would be a big no-no, but using 1e-15 or so ought to be
safe.

Of course, the right way to do meshing (for any problem that doesn't
happen to have exactly one very extreme singularity) is with a
fixed-point scalar class rather than floating point... but it's going
to be a long long time before we consider making libMesh do things
like that.
---
Roy