BTW, the first two posts where I just repeat your last post were not posted by me.. I think. I just posted the last one and was close to taking a video of me submitting my post and getting reposts of yours out of it.

Perhaps the moderation team could delete the last two re-posts of Sanders post. They were not intended, and I have no idea how they got there.

Cheers,

Marco

To paraphrase the creators: the site has multiple servers/databases which are synchronised slowly. I see yours instantly, but that just means I'm logged on to a 'good one' I guess. Sometimes it is also slow for me. Not this time though... Speed improvements would be welcomed indeed @Vitaliy Kaurov. Especially the groups and the main overview load very slow.

I experience huge delays on the update of the community. I receive emails of your posts and they only show up in the browser long after that.

Cheers,

M.

Hi Leslaw,

What worries me is the general observation of Marco: "You can play a bit with the parameters to improve on this." How one can know which parameters to play with and in which way? Are not the solvers automatic in some sense?

Well, Mathematica automatically chooses very reasonable parameters (in most cases). It is just that you require this extremely high precision/accuracy. There are very few applications in the sciences/engineering where that would be useful. So in this particular case you have to instruct Mathematica a little bit. The main issue is what Sander raises:

"Even though you may specify AccuracyGoal->n, the results you get may sometimes have much less than n-digit accuracy."

So, it may be a bit more complicated than just saying what Accuracy you want. But with a little trial and error you can often increase the Accuracy sufficiently to get the digits you need. It turns out that in this case you also want to change to a particular integration method, but without it you run into an error message/warning that exactly tells you what to do.

Also, I am struck by the fact that one has to increase MaxSteps a hundred times or so only in order to get a few more accurate digits. Is this normal? The cost increase is enormous.

The algorithms that the Wolfram Language uses are quite "clever", i.e. better than what I am going to describe now. If you used a first order algorithm the general idea is that the error is proportional to the step size. More or less one tenth of the step size gives you one more digit. If you have a second order scheme then one order in the step size gives you two output orders. You buy this with more evaluations of the right hand side of the ODE, so it gets computationally a bit more expensive, too. This is only a quite rough statement of the idea, but it shows that you have to work for some more digits. Also note that there are some quite sensitive systems where small errors grow exponentially fast. An example would be weather predictions: some more accuracy in the initial conditions only increases the prediction horizon a tiny little bit. Your system is somewhat better behaved.

So in summary, this behaviour might be expected.

Cheers,

Marco

Hi Sander,

yes, I had that clear. The point is that the first approach might be to crank up the Accuracy/Precision and hope that it'll work. But it did not. Needs e.g. explicit method for integration etc.

Cheers,

Marco

"Not quite what you want though."

Also note the AccuracyGoal documentation page:

"Even though you may specify AccuracyGoal->n, the results you get may sometimes have much less than n-digit accuracy."

AccuracyGoal is a goal, but it might not reach it (everywhere).

Hi Sander,

I find it a bit worrying that that code works on your machine but not on mine; doesn't work on MMA11.

Cheers,

M.

Even the error messages have documentation:

ref/message/NDSolve/mxst

which explicitly tell you that you can increase MaxSteps.

Also note the AccuracyGoal documentation page:

"Even though you may specify AccuracyGoal->n, the results you get may sometimes have much less than n-digit accuracy."

Hello,

OK, you are right, increasing WorkingPrecision helps, so that I wrote a new version of my test code:

(* Analytical solution, assuming finite interval L, just to avoid any potential controversy regarding the right choice of L to mimic infinity *)

   uanal[x_,s_,b_]=-(AiryAi[s+x]*AiryBi[s+b]-AiryAi[s+b]*AiryBi[s+x])/(AiryAiPrime[s]*AiryBi[s+b]-AiryAi[s+b]*AiryBiPrime[s]);

   s=2;

   L=10;

   ndigits=32;

   sol=NDSolve[{u''[x]-(s+x)*u[x]==0,u'[0]+1==0,u[L]==0},u[x],{x,0,L},WorkingPrecision->50,PrecisionGoal->30];

   uappr[x_]=First[u[x]/.sol];

  u0=N[uappr[0],ndigits]

        0.65782402587273264492979577402005

  u0acc=N[uanal[0,s,L],ndigits]

       0.65782402587268160074874669507081

  rerror=u0/u0acc-1  

       7.75954952106876733e-14

As can be seen, a relative error about 8e-14 is now achieved. However, please note that I requested AccuracyGoal->30. I don't see a way to obtaining such accuracy, but I need at least 32 accurate digits. Setting AccuracyGoal->32 yields the following solution failure:

sol=NDSolve[{u''[x]-(s+x)*u[x]==0,u'[0]+1==0,u[L]==0},u[x],{x,0,L},WorkingPrecision->50,PrecisionGoal->32];

    NDSolve:mxst: Maximum number of 10000 steps reached at the point x== ...etc.
    NDSolve:bvaux: Unable to solve auxiliary system for boundary conditions at x == 0

So, Please tell me how to achieve my goals.

Leslaw

Hello,

Thank you for responding. Yes, I have tried changing the independent variable, but this creates a problem (as it seems) that we then have infinity * zero in the term (x+s)*u[x] at the right boundary. In general, whatever approach I try, I get troubles. Here you are, this is one very simple code:

s=10; L=10; sol=NDSolve[{u''[x] - (s+x)*u[x] == 0, u'[0] + 1 == 0, u[L] == 0}, u[x], {x, 0, L}, PrecisionGoal -> 10]

   This causes the message:
   The equations derived
   from the boundary conditions are numerically ill-conditioned. The boundary 
   conditions may not be sufficient to uniquely define a solution. The computed 
   solution may match the boundary conditions poorly.

usol[x_]=First[u[x]/.sol]

   (* Here you can call *)
   Plot[usol[x], {x, 0, 10}, PlotRange -> {0, 1}];
   (* to see that L=10 is a reasonable replacement of infinity *)

u0=usol[0] //N

   gives 0.713536

(* analytical solution at x=0 *) u0acc=-AiryAi[s]/AiryAiPrime[s] //N

   gives 0.657824

rerror=u0/u0acc-1

   gives 0.0846915, that is 8 percent error, which is pretty large compared to the PrecisionGoal -> 10 setting
   Please note that I need PrecisionGoal->32 or more ( I mostly need the solution at x=0 )

Leslaw

Without an example and the code you tried no one will be able to help you effectively, post your code, and your analysis of the n = 2--5.