I'll reply to Sander's post before I can see it:

Yes, I have read that, too. Would be good to know how this works exactly. I've got several computers on my desk. The all update slowly, but at different times.

Also, I am not complaining, but we are currently using this thread nearly like a chat. I guess that's why the delay becomes more of an issue. In understand that the Community is not quite a chat-room, which might be another idea for collaborative work. ;-)

Cheers,

Marco

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

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.

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.

"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).

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

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."

What about 10.4(.1)? I get the same result in both.

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

Did you change the independent variable so that the range of the problem is from 0 to 1 rather than 0 to infinity?