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

@Mac Dude It is specific to 2D Math input mode, and will not occur in 1D Maple Notation input mode.

Basically, if one enters an assignment to a function call, such as f(t):=t^2 then a diambiguation dialogue popup window appears, and one gets given the choice between assigning to f's remember table, or assigning a procedure like proc(t) t^2; end proc to f.

In 1D mode, it's always an assignment to f's remember table. And if `f` was previously unassigned then it gets a remember table, ie. it is assigned a proc with a remember table. It sounds like that's what you're seeing in your Variables palette. For example, as 1D Maple Notation input,

restart:
f(t):=t^2:
eval(f);
op(4,eval(f));

It is unfortunate that if one does it in 2D Math and chooses function definition instead of remember table assignment then the GUI and Typesetting mechanism doesn't replace the 2D Math input with t->t^2 or similar. So it doesn't bother to teach a syntax which works unambiguously in all interfaces and entry modes.

One can also set the default 2D Math parser interpretation of such assignments. See the Typesetting,Settings help-page and the `functionassign` option.

@Mac Dude It is specific to 2D Math input mode, and will not occur in 1D Maple Notation input mode.

Basically, if one enters an assignment to a function call, such as f(t):=t^2 then a diambiguation dialogue popup window appears, and one gets given the choice between assigning to f's remember table, or assigning a procedure like proc(t) t^2; end proc to f.

In 1D mode, it's always an assignment to f's remember table. And if `f` was previously unassigned then it gets a remember table, ie. it is assigned a proc with a remember table. It sounds like that's what you're seeing in your Variables palette. For example, as 1D Maple Notation input,

restart:
f(t):=t^2:
eval(f);
op(4,eval(f));

It is unfortunate that if one does it in 2D Math and chooses function definition instead of remember table assignment then the GUI and Typesetting mechanism doesn't replace the 2D Math input with t->t^2 or similar. So it doesn't bother to teach a syntax which works unambiguously in all interfaces and entry modes.

One can also set the default 2D Math parser interpretation of such assignments. See the Typesetting,Settings help-page and the `functionassign` option.

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

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

@student302 Could you upload your actual (full) worksheet that contains this error, into a new Comment in this thread, and mention which Maple version and operating system?

@student302 Could you upload your actual (full) worksheet that contains this error, into a new Comment in this thread, and mention which Maple version and operating system?

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

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

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

exact0.mw

acer

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

exact0.mw

acer

Apart from reducing Digits (ie. keeping it at the default, 10) there may be another easy way to speed up some of this kind of calculation.

The idea is simple, if the parameter(s) hasn't changed very much -- from the previous iteration to the current one -- then the numerical solver might sometimes be able to converge to a new root quite quickly using the previous iteration's root as the new starting guess.

Usually, fsolve will try and pepper the multivariable solution space with random starting points, and we hope that one will converge. (This is also why it takes long to fail completely, by the way.)

So an ajustment to the methodology could be like this: first try the previous iteration's root as the new starting point. If that fails to converge then call fsolve without specifying a starting point, and let it proceed as usual.

At Digits=10 the old methodology takes 40 seconds to get all those 45 discovered roots for `n1` between -3.99 and 7.01. domain_try1.mw

Using the above methodology it takes about 3 seconds.  domain_try2.mw

Computations run in 64bit Maple 16.01 on Windows 7.

acer

Apart from reducing Digits (ie. keeping it at the default, 10) there may be another easy way to speed up some of this kind of calculation.

The idea is simple, if the parameter(s) hasn't changed very much -- from the previous iteration to the current one -- then the numerical solver might sometimes be able to converge to a new root quite quickly using the previous iteration's root as the new starting guess.

Usually, fsolve will try and pepper the multivariable solution space with random starting points, and we hope that one will converge. (This is also why it takes long to fail completely, by the way.)

So an ajustment to the methodology could be like this: first try the previous iteration's root as the new starting point. If that fails to converge then call fsolve without specifying a starting point, and let it proceed as usual.

At Digits=10 the old methodology takes 40 seconds to get all those 45 discovered roots for `n1` between -3.99 and 7.01. domain_try1.mw

Using the above methodology it takes about 3 seconds.  domain_try2.mw

Computations run in 64bit Maple 16.01 on Windows 7.

acer

@jschulzb Can we suppose that your newer question is your focus for this issue now, and that this earlier thread is not so pressing?

By the way, you can use the "branch" item and the botton of a post/question/answer is you would like to ask some new related question and have mapleprimes automatically put cross-referencing links on both of old and new.

The combination of dsolve events and parameters is very powerful. That, along with a good numeric DAE solver, makes the cornerstone of MapleSim, IMO. But the documentation and examples for events/parameters in Maple are a little thin relative to its power and usefulness.

PatrickT has asked some questions here about `events` and `parameters` in the dsolve numeric solver, which might help shed some light.

Without seeing you full code, I might hazard a guess that you are going for some implicitplot, and just need a little help figuring out the beast that could be plotted (since it will be a procedure that sets the parameters according to the arguments, and then runs until events hit/miss, and then returns some indicative scalar... or something like that).

@jschulzb Can we suppose that your newer question is your focus for this issue now, and that this earlier thread is not so pressing?

By the way, you can use the "branch" item and the botton of a post/question/answer is you would like to ask some new related question and have mapleprimes automatically put cross-referencing links on both of old and new.

The combination of dsolve events and parameters is very powerful. That, along with a good numeric DAE solver, makes the cornerstone of MapleSim, IMO. But the documentation and examples for events/parameters in Maple are a little thin relative to its power and usefulness.

PatrickT has asked some questions here about `events` and `parameters` in the dsolve numeric solver, which might help shed some light.

Without seeing you full code, I might hazard a guess that you are going for some implicitplot, and just need a little help figuring out the beast that could be plotted (since it will be a procedure that sets the parameters according to the arguments, and then runs until events hit/miss, and then returns some indicative scalar... or something like that).