MaplePrimes - answers and comments on Question, Plotting the Parameters that cause a D.E. Event to Execute

events

acer — Tue, 09 Oct 2012 21:35:16 Z

I'm not sure that I understand why fsolve has to be used. Can't the specified events alone reveal success versus failure?

If I understand you then success only occurs when y(t)=3.05 (the height of the basket) and D(y)(t)<0 (meaning the ball is moving downward). If the ball reaches its maximal height before y(t) ever equals 3.05 then that is an easy case of failure.

You can access the values of y(t), x(t), and D(y)(t) following an event trigger by using the special keyword 'last'.

Strict equality testing might not work best, if dsolve is allowing itself any numeric error. And I suppose that you would ideally want to restrict success according to whether the ball (of nonzero width) is going to physically clear the hoop? That math (events) for that could get tricky. In other words, now it gets fun(?!). For example, D(y)(t) would have to be qute a bit less than zero, for the ball to score.

Is this below close to what you want? (About 17 sec to get the plot, on am Intel i5.) If I got it all wrong then hopefully you can adjust and correct.

event0.mw

acer

exact dsolve

acer — Wed, 10 Oct 2012 00:53:03 Z

The numeric results computed above seem to agree with the following results from symbolic dsolve.

exact0.mw

acer

Application Center

acer — Wed, 10 Oct 2012 07:51:16 Z

In case this topic is of general interest: Dr. Robert Lopez has written Classroom Tips and Techniques: "Events" and the Numeric Solution of ODEs, which is on the Application Center.

acer

compile=true

acer — Thu, 11 Oct 2012 08:23:02 Z

If the compile=true optional argument is supplied in the dsolve,numeric call then the total time to produce the associated implicitplot is reduced by about 20% on my Maple 16 system.

I confess that is news to me. I knew that dsolve,numeric has had (at least one form or another of) compilation functionality, for some time now. But I had thought that it was, for some releases now, automatically invoked by Maple.

I suspect that for many systems of simply expressed DEs (no special functions) the performance benefit to using this option can be considerable, especially for parametrized ODEs where the computation may be done for many sets of parameter values.

The machinery of `implicitplot` may incur a significant portion of overhead in this example, but a few other simple tests suggest to me that some other examples (eg. dsolve,numeric,parameters hooked up to GUI Slider Components, or invoked to produce traditional animations) may benefit a great deal more. Maybe up to 50% or so!?... I'll have to revisit some old posts.

acer

Thanks

jschulzb — Thu, 11 Oct 2012 17:13:58 Z

Cool! Thank you very much! Graphing is taking me from ~33-50 seconds on a laptop with an AMD Phenom Quad-core processor. Might I ask if your using a desktop ? Otherwise I'm switching to Intel!

I can't find any information about the compile=true option in dsolve, but I can 'compile the procedure', but it doesn't make much difference.

Also whats the purpose of your try X(200); catch "cannot evaluate": end try; statment?

compile=true

acer — Thu, 11 Oct 2012 18:29:19 Z

@jschulzb With the compile=true option in the (single) call to dsolve it takes approximately 13 sec on an Intel i5 on 64bit Linux in Maple 15 with gcc as the compiler, 15 sec on that i5 in Maple 16, and about 17 sec on an i7 in 64bit Maple 16 on Windows 7 with the free MSVC++ compiler.

event0compiled.mw

Those timings seem to be about 15-20% faster than without the compile=true option. For the compile=true option to work I suspect that one needs Compiler:-Compile to also function OK. Hmm, I'm not sure where dsolve,numeric's compile=true option might be documented. (!)

That try..catch might not be necessary. I guess I was concerned that if the solver halted with an error that the subsequent bits to extract and test the "last" computed point might get skipped.

There is overhead in implicitplot, which might be overshadowing the performance benefit of using compile=true here. In some other examples where I only did multiple calls to the emitted procs, or multiple calls to `odeplot`, I saw even more timing gains. I suspect that this would also be very useful when doing parameter optimization (as in Optimal Control).

If I may be allowed a general remark: for simple models an exact symbolic result might be obtained, as is the case here. But of course for more involved systems computing an exact result in full might not be possible or practical. Hence numerical solving gets its day in the spotlight. For simple systems and problems it might even be that using a rootfinder like fsolve to find a special value's occurrence is practical. And it's easier to implement an fsolve search using dsolve's output procs than it is to set up even the simplest of events. But in general as parametrized ode systems and the events get more complicated, or for parametrized systems which must be run many times to search the parameter space, using dsolve's event handling mechanisms should be the clear performance winner. The combination of dsolve's events and dsolve's parameters can be very powerful. Combine that with top-notch DAE solvers and it's possible to build a modelling environment as powerful as... MapleSim.