MaplePrimes - answers and comments on Question, Second derivative for dsolve numeric solution of second order BOUNDARY VALUE PROBLEM.

More of an observation

tomleslie — Sat, 12 Dec 2020 02:07:11 Z

In your "toy" example

diff(u(x), x, x) = u(x), u(0) = 2, u(1) = 1

why would Maple need to return diff(u(x), x, x) explicitly? Since diff(u(x), x, x) = u(x), all it needs to return is u(x) - since these functions are obviously identical.

dsolve(..,numeric) will never return values for the "highest order derivatives" in an ODE system, because the ODE system itself will allow these to be computed in terms of lower order derivatives (which dsolve(...,numeric) will return).

There are cases where the highest-order derivatives cannot be (easily) isolated and hence computed from the information which dsolve(..,numeric) returns - this is usually where the "trick" of adding a subsidiary equation such as diff(u(x), x, x) = v(x) may be useful.

So just how difficult is your actual problem??

zeroth order approach - using pdsolve

Scot Gould — Sat, 12 Dec 2020 03:58:53 Z

For fun, I tried out your toy problem. In the end, I agree with Tom - I don't see the difference and neither does Maple. I used pdsolve, not dsolve.

Write out differential equation and boundary value conditions

(1)

(2)

(3)

Download pdsolve.mw

Differentiating the bvp and what happens for ivp's.

Preben Alsholm — Sat, 12 Dec 2020 15:14:44 Z

restart;
ode1:=diff(u(x), x, x) = u(x)*sin(x);
ode2:=diff(ode1,x);
bcs:=u(0)=2,u(1)=1,(D@@2)(u)(1)=sin(1);
Digits:=10: # The default
res:=dsolve({ode2,bcs},numeric,abserr=1e-13);
plots:-odeplot(res,[x,diff(u(x),x,x)-u(x)*sin(x)],0..1,caption=typeset(diff(u(x),x,x)-u(x)*sin(x)));

A comment or rather a rhetorical question:

If you were to design an algorithm for dsolve/numeric (bvp or ivp) that returned the highest derivative too, what would you make it return other than the right hand side?
#####
Looking at what `dsolve/numeric` does to an ivp like this:

restart;
ode1:=diff(u(x), x, x) = u(x)*sin(x);
ode2:=v(x)=diff(u(x),x,x);
ics:=u(0)=2,D(u)(0)=0;
#debug(`dsolve/numeric`);
res:=dsolve({ode1,ode2,ics},numeric,abserr=1e-13,relerr=1e-10);
plots:-odeplot(res,[x,v(x)-u(x)*sin(x)],0..1,caption=typeset(v(x)-u(x)*sin(x)));

If you remove the # then the debugging output reveals what dsolve/numeric does here:

INFO["proc"] := proc(N, X, Y, YP) local Z1; Z1 := Y[1]*sin(X); Y[3] := Z1; if N < 1 then return 0; end if; YP[2] := Z1; YP[1] := Y[2]; 0; end proc;

As you see the right hand side is kept in the local Z1 and Y[3] (i.e. v) gets that value as does YP[2] i.e. u''.
This simply means that the right and side is returned for v.

@tomleslie Analytically they're identic...

Robert Matlock — Sat, 12 Dec 2020 03:13:46 Z

@tomleslie

Analytically u_xx and u are identical, but numerically they might not be. That's part of what I want to find out.

And in my real problem, the second derivative, u_xx = f(u(x),s(x)), where f is a complicated nonlinear function of u(x), and s(x) is a piecewise continuous coeffient (piecewise in the independent variable x). So I am more concerned that that f(u,s) might deviate from u_xx than in the toy problem.

Setting f(u(x),s(x)) = 0 and solving for x gives an analytical prediction where the inflection should be. The numerical result is very close to this analytical prediction, but not quite equal to it. Is the analytical prediction wrong or is the numerical solution inaccurate? The dependent variable, u(x) is almost linear at the inflection point, so near the minimum, du/dx is pretty flat -- small changes in u lead to large changes in x. Hence I need the most accurate calculation of u_xx that I can muster. Currently I'm stuck with finite difference approximations applied to dsolve's estimate of u.

Eventually, I would like to prove analytically that the f(u(x),s(x)) = 0 prediction of the location of the inflection point is correct. Before putting in the effort to do that, though, I want some numerical confirmation that the prediction is probably correct.

Another problem is that it's hard to get dsolve to converge for abserr > ≈ 10^-4, perhaps because of the piecewise coefficient -- so I can't calculate the solution with unlimited precision.

How would it be done?

Carl Love — Sat, 12 Dec 2020 04:52:29 Z

@Robert Matlock Suppose that dsolve did provide the highest-order derivative in its output. By what magic process would it compute that other than the way that we're describing to you?

@Carl Love Clearly you've not read what...

Robert Matlock — Sat, 12 Dec 2020 05:21:52 Z

@Carl Love

Clearly you've not read what I wrote above. Nor have you paid attention to the fact that I posed a simple problem for the purpose of illustration -- the actual problem I need to solve is not solvable analytically.

I am not sure how error is tallied on quantities calculated by dsolve. If it is independent for each quantity, then a reasonable upper bound for |u_xx(x) - u(x)| is |u_xx(x) - u(x)| ≤ 2*abserr -- i.e. for numerical results u_xx ≠ u(x).

Second, on June 10, 2012, Dave L 472 posted the following regarding higher order derivatives from dsolve numeric:

"There are have been quite a few questions on Mapleprimes, about numerically deriving additional information from the solutions returned by dsolve(..,numeric). That includes higher derivatives, integrals, inverting for particular function values, etc.

As it happens, I was having coffee last week with the principle developer of dsolve,numeric, and I asked him pointedly about all this. The answer I got back was pretty unequivocal: dsolve itself is the best thing to use in these situations, in general, because it will try to ensure that the requested accuracy (whether specified by default or explicit tolerance options) is attained for the requested quantities.

Consider fdiff (or evalf@D, which has a hook to fdiff). It will not compute as carefully as dsolve,numeric would. If dsolve,numeric detects difficulties near a requested point then it can automatically adjust stepsizes, etc. But that won't happen when using fdiff."

Let's compare the two methods given so far, pushed out only as far as the modest value of t=2.0. Fortunately we can compare against the exact result, which can be evalf'd at high working precision.

As we can see below, the result from dsolve,numeric itself is pretty much accurate up to its own default tolerances (which is incorporated into the procedures which it returns). The nested fdiff results, on the other hand, get wildly wrong as Digits changes."