Thanks Wolfgang and Jean-Paul for explanations.

Yes, I agree, the issue is definitely related to round-off error. But I 
still don't understand why the mapping fails, if the vertex coordinates 
read in from my .msh file are apparently stored as doubles...
Anyway, yes, the problem is easily overcome by "manipulating" the values 
before mapping.

Best,

Giovanni



On Friday, July 21, 2017 at 5:29:29 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 07/21/2017 02:39 AM, Giovanni Di Ilio wrote: 
> > 
> > So, let's just consider the coordinate y1. If we approximate the value 
> to 
> > 0.49999999999882*2* the mapping will be ok. However, if we try one of 
> the 
> > following, as example: 
> > 
> > y1 = 0.49999999999882*1* 
> > y1 = 0.49999999999882*21 
> > 
> > *interesting enough, the mapping will fail again. 
> > Another test: I add say two random digits to each vertex coordinate: 
> > 
> > x1 = 5.399999999999241*21* , y1 = 0.4999999999988218*21* 
> > x2 = 5.499999999999598*21* , y2 = 0.499999999998822*21* 
> > x4 = 5.399999999999546*21* , y4 = 0.59999999999853*21* 
> > x5 = 5.499999999999902*21* , y5 = 0.59999999999853*21* 
> > 
> > Now it works again...this is mind-blowing. 
>
> No, this is round-off error in action :-) Floating point numbers have only 
> approximately 16 digits of accuracy. The differences between the numbers 
> you 
> have are at approximately at the level of round-off, and any computation 
> you 
> do with these numbers will add to the effect of round-off. 
>
> If you have numbers where you depend on differences at the level of 
> round-off, 
> arithmetic works very differently than for regular real numbers. They 
> behave 
> more like integers because every operation involves rounding to the next 
> representable floating point number, and this rounding operation changes 
> the 
> number significantly (relative to the differences between numbers you are 
> considering). 
>
> There is nothing you can do about this other than not rely on differences 
> that 
> are this small relative to the absolute size of the numbers. One way you 
> can 
> avoid this is if you have a small domain somewhere in R^2, move it to the 
> origin so that the relative distance between points is no longer small 
> compared to the distance from the origin. 
>
> Best 
>   W. 
>
> -- 
> ------------------------------------------------------------------------ 
> Wolfgang Bangerth          email:                 bang...@colostate.edu 
> <javascript:> 
>                             www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to