On 22 Apr 2017, at 15:28, Xu, Hui <hui.xu@imperial.ac.uk> wrote:

Hi All,

From Ankang’s report about polylib.cpp, it was said that

“Problem happens when z is very close to zj but their distance is still greater than EPS, since at this situation the formula in hj contains subtraction of two very close (double) float numbers, which causes heavy loss of accuracy."

It seemed that the double-precision floating-point format  was being challenged.

Double precision only gives 15-17 significant decimal digits precision.

(See wikipedia)

Sign bit: 1  bit

Exponent: 11 bits

Significant precision: 53 bits (52 explicitly stored) -> 15-17 significant decimal digits 

However, we could have a more professional way to circumvent/reduce "subtractive cancellation".

See the example given below and it can be a way to do some modifications.

The codes:

#include <iostream>

#include <limits.h>

#include <float.h>

#include <iomanip>

#include <cmath>

using namespace std;

typedef std::numeric_limits< double > dbl;

double scale=1e16;

int main(){

double a    = 1.111111112355343;

double b    = 1.111111112344554;

cout<< setprecision(30)<< a << endl << setprecision(30) << b <<endl;

double expn = floor(log10(abs(a-b)));  // Assuming that the two numbers are very close to each other and  both are greater than 1. The difference is approaching to the limitation of significant digits.

double a0 = a*pow(10,-expn-1)-floor(a*pow(10,-expn-1));  

double b0 = b*pow(10,-expn-1)-floor(b*pow(10,-expn-1));

double a1 = round(a0*pow(10,15+expn+1));                     // get rid of rubbish

double b1 = round(b0*pow(10,15+expn+1));                     // get rid of rubbish

cout<< setprecision(30)<< a1 << endl << setprecision(30) << b1 <<endl;

cout<<"The difference between two number : "<<endl<< setprecision(20)<< a-b <<endl;

cout<<"Reference Value :"<<endl

    <<"                  92686996014.459171378255630735" <<endl;

cout<<"Calculations    : "<<endl;

cout<<"Direct Calc     : "<<setprecision(30)<<1/(a-b)<<endl;

cout<<"Optimised Calc  : "<<setprecision(30)<<1e15/(a1-b1)<<endl;

return 0;

}

The output:

1.11111111235534298913307793555

1.11111111234455406382437558932

55343

44554

The difference between two number : 

1.0788925308702346229e-11

Reference Value: 92686996014.459171378255630735

Calculations       : 

Direct Calc         : 92687637682.8190765380859375

Optimised Calc  : 92686996014.45916748046875

Hope it could be useful.

Cheers,

Hui

On 21 Apr 2017, at 19:47, Ankang Gao <gaoak@pku.edu.cn> wrote:

Hi,

I use the same Lagrange interpolation polynomial as Nektar::LibUtilities::GaussPoints::LagrangePoly or Nektar::LibUtilities::PolyEPoints::LagrangePoly. The Polylib.cpp file I modified is attached, and the differences between this file and the original one are shown in another attachment 'difference.txt' which is obtained by command "diff" in linux OS.

After this modification, the main numerical error of funtion PhysEvaluate is contributed by NewtonIterationForLocCoord, which is 2.e-6 maximum in my tests with 12 points each direction in a quad geometry.

I'm glad to see that my report is of use to improve nektar++. In my opinion, Nektar++ is a wonderful code, and it has become the main numerical tool in my research. I am looking forward to nektar++ getting more and more powerful.

Ankang

-----原始邮件-----
发件人:"Sherwin, Spencer J" <s.sherwin@imperial.ac.uk>
发送时间:2017-04-21 22:51:00 (星期五)
收件人: "Ankang Gao" <gaoak@pku.edu.cn>
抄送: nektar-users <nektar-users@imperial.ac.uk>
主题: Re: [Nektar-users] 2 bugs and 1 question

Hi Ankang,

Sorry it has taken rather long to get back to you. Thanks for your clear explanation which I think is very interesting and we should do something about this. Do you have a modified polylib.cpp we can include.

I am not sure if the papers that Dave forwarded offer a more robust way of evaluating the lagging polynomial near the quadrature points since that is the only other modification I can think we might consider.

I am cc’ing Mike so he can also perhaps comments on this point.

Cheers,
Spencer.

> On 14 Apr 2017, at 13:06, Ankang Gao <gaoak@pku.edu.cn> wrote:
>
> Hellow,
>
> I have found two bugs in the codes, and I listed them in the attachment.
>
> I have a question about why the backward differentiation formula starts after m_pressureCalls>2, in function
> void Nektar::Extrapolate::AccelerationBDF(Array< OneD, Array< OneD, NekDouble > > & array).
> Since when m_pressureCalls=2, we can already get a first order accuracy result.
>
>
> thanks
>
> Ankang
> <reportbug_question.pdf>_______________________________________________
> Nektar-users mailing list
> Nektar-users@imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users

Spencer  Sherwin
McLaren Racing/Royal Academy of Engineering Research Chair,
Professor of Computational Fluid Mechanics,
Department of Aeronautics,
Imperial College London
South Kensington Campus
London SW7 2AZ

s.sherwin@imperial.ac.uk
+44 (0) 20 759 45052

<Polylib.cpp><difference.txt>_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users