cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X

Awfull integration

Al2000
1-Visitor

Awfull integration

Hi people. Toying with Mathcad I found an unexpected (to me) result while plotting a function that integrates a piecewise defined function.

I wander is some of you gurus that are using MC for many years can give me some insight of what's happening.

My guess is that MC can't integrate piecewise defined functions as well single functions.

I'm using an old version of MC so I'm attaching a print screen of the third graph, just in case it looks OK in newer versions.

Saludos,

Al
11 REPLIES 11

It does not plot "awful" for me !



jmG

It is a typical numerical integration issue. Because you have steps in your data (rather than smooth transitions) the termination conditions on the numerical integral get fooled into stopping too soon.
This is common to all programmes and packages and is an indication of the gap between the assumptions you make and those that the programmer/mathematician made in creating the method.
It provides an opportunity for further learning 😉

Try splitting the offending integral into three bands, somewhere near 'a' and 'b' (but not always exact) and see how the 'error' varies.

i.e. integral [0,a-e] + [a-e,b+f] + [b+f,r]
with e & d being the small deviations.

Philip Oakley

Just numeric problems.

You are correct that Mathcad cannot integrate piecewise defined functions as well as it can analytic functions. The algortithm for numeric integration assume continuous derivatives, through at least two derivatives, and generally require bounded second derivatives. Discontinuities, even just corners, don't work all that well. Generally if you have a function defined piecewise (and the joins are not completely smooth) it is best to break up integrals and calculate separate integrals for each of the ranges.

Here the problem is the implied sampling (true any numeric algorithm -- the integrand can only be evaluated at a finite number of discrete points) and the relationship of the sampling points to the sharp peak. Because that peak contributes so much to the integral, the effect is quite noticeable. Note that the approximation as a sum produces the same sort of jagged result.

You can improve the integral considerably by using a smaller value of TOL. At 1E-9 the curve is fairly smooth. Similarly you can increase the quality of the Euler sum by increasing the number of intervals. 300 (rather than 30) gives a reasonable looking answer).

But calculating a whole lot if integrals this way (varying the upper limit) is a slow, and not all that accurate, way of doing the calculation. It is much faster, and often more accurate, to set it up as a differential equation and then use one of the ODE solvers (I'm partial to Rkadapt, myself). If you nose about the collaboratory you should be able to find some expamples of doing this.
__________________
� � � � Tom Gutman

At the bottom of your sheet, which you should have corrected as advised, the same oscillation problem appears in the raising front.

jmG

Thanks for all your answers, now I have a better understanding of the problem.

Saludos,

Al

Here's how to set it up using the ODE solvers. While Rkadapt doesn't fully handle the discontinuities, it lets you know when it has problems.
__________________
� � � � Tom Gutman

On 7/30/2009 6:50:04 PM, Tom_Gutman wrote:
>Here's how to set it up using
>the ODE solvers.

Fascinating... 🙂

Maybe its time to take a look at Mathcad ODE solving capabilities... Thanks for taking time to show us this method.

Saludos,

Al

On 7/31/2009 12:22:59 PM, Al2000 wrote:
>On 7/30/2009 6:50:04 PM, Tom_Gutman
>wrote:
>>Here's how to set it up using
>>the ODE solvers.
>
>Fascinating... 🙂
>
>Maybe its time to take a look at Mathcad
>ODE solving capabilities... Thanks for
>taking time to show us this method.
>
>Saludos,
>
>Al
___________________________

There is simply no best integrator. So nice the Odesolve works in many applications, for this most simple case in demo, it fails miserably ! The comparison with rkF4 is neither proof that it is better. DE integrators are "ballistic" and by no way can be as accurate than the Romberg iterative. In your example TOL plays a major role as it does for all the options of the drop down numerical integrators. Enjoy and visit at big double arrows.

jmG

rk4 appears to be defective. Rkadapt produces an answer accurate to 13 digits, even with the default TOL of 1E-3. When applied to a quadratic (as in your example) the RK integration should be exact to within computational accuracy. Adding up 10,000 numbers should be accurate to about 12 digits.

Romberg integration is fast. But generally not very accurate.
__________________
� � � � Tom Gutman

>Romberg integration is fast. But generally not very accurate.[Tom Gutman] <<br> __________________

Thanks Tom,

I bet one day you will have generalised the method and tested for best use as a new numerical integrator for future versions. Maybe Fehlberg should be added too.



jmG

The problem in the previous sheet is that Rkadapt is trying to use relative errors. Relative errors don't work very well when the value is zero. This sheet tweaks the calculations to allow integration over the full range.
__________________
� � � � Tom Gutman
Announcements

Top Tags