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

@Scot Gould 

You've shown that u = u_xx in the analytical problem -- not in the numerical problem. And your result is for the toy problem that I posed for illustration; my real problem is nonlinear and not analytically solvable.

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

Thanks. That fixed the problem. Why doesn't Maple follow Windows conventions in a Windows program? I lost 3 hours yesterday because of this. 

Thanks. That fixed the problem. Why doesn't Maple follow Windows conventions in a Windows program? I lost 3 hours yesterday because of this.