• br
  • entries
    71
  • comments
    358
  • views
    39,386

ODE Solution --- Fail!!

DrD

1,419 views

   

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.

ODE_Soln_Fail.pdf



6 Comments


Recommended Comments

Hello,

this is an interesting problem. My first thought was, that the cosine function is not all of the solution. Thus I tried to find an analytical solution. With an ansatz e^c*x I end up with following solution: C1*e^-a*x + C2*e^a*x + C3*cos(a*x), though I have not yet checked it in detail. From the initial conditions it follows that C1 = C2 = 0. However, with increasing time the term e^a*x becomes very large. Thus a possible reason for the numerical instability might arise if C2 is near but not exact zero and this term starts to contribute to the solution for large times. I have derived a numerical solution with Python and Numpy, whichhave similar capabilities as Matlab, but are freely available. The instability starts approx. at x=23.

An analytical solution may not be found for more complex problems and thus does not help to check such a numerical solution. Practically I try to check, if a solution makes sense (for an engineer). E.g. the solution has to show a certain behavior (in qualitative sense), if some parameter go to a limit or certain frequencies have to show up in the solution.

Regards,

Alban

Share this comment


Link to comment

Dear Alban,

That was an excellent comment; thank you.

I think you are thinking on the right path, but I think you have missed a part of the problem. I suggest that you go back and go over your analytical approach a bit more thoroughly, because that is where I see an oversight.

I'm glad to hear about the approach with Python and Numpy; I am not familiar with either. It is good to be aware of as many tools as possible.

As I understand your final paragraph, I think you may be mistaken. For some very complex problem, with no evident analytical solution at all, I think it is still necessary to check the computed solution by every possible means. Reasonableness alone is not entirely convincing. For example, suppose we are computing the response of a complicated electrical network. One of the questions of great interest is, "Does the line voltage ever reach or exceed the breakdown voltage of the insulation?" As long as the line voltage is below the breakdown level, the circuit  will function correctly, but if the line voltage exceeds the breakdown voltage on the insulation, a short to ground will result. A solution may look "reasonable" which is to say it goes up and down in more or less the expected manner, but if the computed value is not pretty accurate, we cannot test a threshold concept like breakdown voltage.

Thanks again for an excellent comment. I hope others will seize upon it and run with the ball.

DrD

Share this comment


Link to comment

during my study, some nonlinear equations are difficult to resolve by conventional methods, so, DrD, do you have some advanced approaches to applied for this questions.

thank you!

Share this comment


Link to comment

Dear Ching,

There is no doubt that some nonlinear ODE are difficult to solve. The equation discussed in this post is actually a linear ODE which should put the solution within the scope of most readers who have had a course in differential equations. I have no magic wand for nonlinear ODE.

DrD

Share this comment


Link to comment

DrD, 

I have an experience when we try to goal our windmill for an international certification. The certification body needs working stress for each components (blades, hub, etc.).

Hand calculations give a rather low stress magnitude (easily safe), but very simplified approach.

You standard: stress = [(force/area) + (moment*c/inertia)] x load factors

With all equations, it looks ugly in printed form.

FEA simulations give often higher stress magnitude (still safe), but more catchy looking with graphics and all-that.

The supervisor and me conclude that we need to use FEA output (graphics and stuff) for our document due to its catchy looks. It succeed.

Personally, I agree that as an ME you shouldn't treat every problem the same way. You are not a hammer, who only know to hit everything else, as if they're nails.

Sometimes, hand calculations are OK, other times, FEA simulations/whatever else more suitable, other times logic/common sense prevails.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • br
  • br