# ODE Solution --- Fail!!

**Mechanics Corner**

A Journal of Applied Mechanics and Mathematics by DrD, # 31

Machinery Dynamics Research, 2016

*ODE Solution --- Fail!!*

**Introduction**

Digital computation has become a major tool for engineers, and it is a great benefit. It can also lead to many pitfalls for the unwary. This note is about the latter, a potential pitfall that many engineers risk on a daily basis, most of them with little awareness of the danger.

Early in the development of digital computation, every problem required that the user write a program specific to the problem at hand. If speed was a very important issue, the programs were written in machine language, so that they would execute as fast as possible. If speed was a little less critical, programs were written in so-called "high level languages." This included FORTRAN, BASIC, ALGOL, C, C++, and a host of other such names. But even with a high level language, there was the problem of generating a program for the solution of the specific problem at hand.

As things have continued to evolve, it was soon evident that a lot of the work in writing each program was the same from one problem to the next. The major mathematical operations, such things as numerical integration, matrix operations and the solution of systems of linear equations, plotting, and many other steps were re-usable from one problem to the next. It was natural that this would eventually lead to the development of general purpose programs, able to solve broad classes of problems. This group includes programs like *Mathematica*,* Maple*, *MatLab*, *SciLab*, *Maxima*, *TKSolver*, and numerous others. Most of those just mentioned have built-in capability to solve ordinary differential equations, in some cases by analytical means, and in practically all cases, by numerical means. This has taken the sting out of working with differential equations

from many engineering problems, and we must all be grateful for that.

At the same time, we must also be somewhat skeptical about any general purpose solver when applied to a particular problem. How do we know that the solution generated is correct? How do we even know if it is reasonable? Most of the time, when engineers resort to numerical solutions, it is because there is no readily available analytical solution. Thus, when faced with a problem that cannot be solved in closed form, how can we know when to trust the numerical solution? This is a very serious question, one that all must consider. It you blindly trust a numerical solution, the old excuse, "The computer said it was OK" will not get you very far. The computer cannot be fined, fired, or (in extreme cases) possibly sent to prison, but all of these things can happen to an engineer!

So, what can the engineer do when the differential equation has no known solution? Well, there are several options.

(1) He can resort to any physical principles that apply to the situation. For example, if the system is such that energy should be conserved, then he can add code to calculate the total system energy at every instant. Just verifying that energy is conserved does not "prove" that the solution is correct, but if energy is not conserved when it should be, you can be sure there is an error in the solution.

(2) He can try various approximations that may apply to see if they are in reasonable agreement with the computed solution.

(3) He can verify the solution code by applying it to a similar problem for which there is a known solution. It is this last approach that I want to talk about in this post.

## 6 Comments

## Recommended Comments