thanks pagan, what an embarrassing mistake.

Note:

:"> is the "embarrassed smiley"

thanks pagan, what an embarrassing mistake.

Note:

:"> is the "embarrassed smiley"

@acer 

breathtaking!

after you right-click on the button on the left of "Run code edit region code, before starting" and select ExpandCodeEditRegion how do you get it to close again? I didn't see a "close" button to click on and wasn't sure what to do (so I closed and reopened the worksheet).  Can the equations for scene1, scene2, etc. be accessed and edited? Would it be a lot of work to add a scene3, say? I guess you would add a line like this: elif scenehandle="Scene 3" then ... but didn't see where the equations for scene3 would be written.

In a word, amazing.

Thanks to your suggestions, I have made some progress with the simulations that motivated my questions. Simply catching errors and re-initializing dsolve is not quite enough because, in some cases, the trajectories wonder off in the wrong direction. So I have set up events designed to trigger whenever the trajectories go in forbidden places. I tried to combine try/catch with several conditional statements based on the event triggers and/or the warnings. However, I ran into problems.

One problem with processing the warning messages is that I couldn't make Maple "see" the keyword (StringTools seems to read them from left to right, as pointed out earlier in a different context). For instance:

> sys := diff(y(t),t)=y(t)^2, y(0)=1 :
> sol := dsolve({sys}, 'type'=numeric, [y(t)], 'events'=[[y(t)=0..10,'halt']], 'output'=listprocedure) :
> sol(1):
> lastwarning;
Warning, cannot evaluate the solution further right of .89999999, event #1 triggered a halt
Warning, cannot evaluate the solution further right of .89999999, event #1 triggered a halt
"cannot evaluate the solution further right of .89999999, event #1 triggered a halt"

> StringTools:-Has(cannot,StringTools:-FormatMessage(lastwarning));
> StringTools:-Has(event,StringTools:-FormatMessage(lastwarning));
                              true
                             false

I therefore tried something else. I thought about using eventfired, but a funny thing happened there. I set up events like this:
events = [ [r(t) = -1 .. 3/40, 'halt'], [u(t) = -5 .. 0, 'halt'] ] :

but the numbering of the events does not appear to be consistent. The first time I run the simulation I get:

Warning, cannot evaluate the solution further left of -38.078909, event #2 triggered a halt

The second time I get this:

Warning, cannot evaluate the solution further left of -38.078909, event #4 triggered a halt

and then #6, and so on. For what is obviously the same event. I guess I may need to use eventclear before each simulation, but my earlier attempts failed. I will probably need to think about this some more, but in the meantime I tried another approach.

    for i to n do
        try
            sol := dsol(endpoint) ;
            if abs(rhs(rhs(sol('last')[1]))) >= abs(10) then 
                break ;
            else
                ln(0); # forcing an exception
            end if ;
        catch:
            ini1 := whatever
            dsol('initial'=ini1) ; # re-initialize dsolve
        end try ;
    end do ;
    ini1 ; # return modified initial conditions
    end proc :

In the above I create an error that will be caught by catch conditional upon dsolve not going "far enough", here the value abs(10).

A self-contained portion of my simulations is attached for reference, if anyone is curious about this. There are still things I need to fix. To do: It would be nice if I could be more specific about what to do when certain events trigger. I probably should write the events like this, and find a way to consistently keep track of them:
events = [ [r(t) = -1, 'halt'], [r(t) = 3/40, 'halt'], [u(t) = -5, 'halt'], [u(t) = 0, 'halt'] ] :

EDIT 1: I have uploaded an updated version of my simulations in progress. I did manage to use event triggers in the loop. At this point this scheme has only managed to compute initial conditions and trajectories for a fraction of the points of interest, but I do hope that further tweaking with the randomizing scheme or the digits or something will be made to work...

EDIT 2: Got it to work, at last! I had a number of problems in my code. One mistake was that I had augmented the procedure to take a "seed" as input, in order to be able to replicate future simulations exactly. But I had set randomize() in such a way that it was using the same seed for every trial I was running, so that my procedure was not random at all. Another problem I had was that I had set one of the events to trigger too early, forcing an exception and discarding trajectories that should otherwise have been accepted (this mistake came from the fact that the trajectory undergoes a sort of "bifurcation", changing direction somewhere near my 26th trajectory). There were one or two other problems that no-one could possibly be interested in. The bottom line is that it's been fixed and works as expected. Surely inefficiencies and awkward bits of coding remain...

A big thank you to my mentors at mapleprimes!

DynamicsMapleprimes2.mw

Thanks to your suggestions, I have made some progress with the simulations that motivated my questions. Simply catching errors and re-initializing dsolve is not quite enough because, in some cases, the trajectories wonder off in the wrong direction. So I have set up events designed to trigger whenever the trajectories go in forbidden places. I tried to combine try/catch with several conditional statements based on the event triggers and/or the warnings. However, I ran into problems.

One problem with processing the warning messages is that I couldn't make Maple "see" the keyword (StringTools seems to read them from left to right, as pointed out earlier in a different context). For instance:

> sys := diff(y(t),t)=y(t)^2, y(0)=1 :
> sol := dsolve({sys}, 'type'=numeric, [y(t)], 'events'=[[y(t)=0..10,'halt']], 'output'=listprocedure) :
> sol(1):
> lastwarning;
Warning, cannot evaluate the solution further right of .89999999, event #1 triggered a halt
Warning, cannot evaluate the solution further right of .89999999, event #1 triggered a halt
"cannot evaluate the solution further right of .89999999, event #1 triggered a halt"

> StringTools:-Has(cannot,StringTools:-FormatMessage(lastwarning));
> StringTools:-Has(event,StringTools:-FormatMessage(lastwarning));
                              true
                             false

I therefore tried something else. I thought about using eventfired, but a funny thing happened there. I set up events like this:
events = [ [r(t) = -1 .. 3/40, 'halt'], [u(t) = -5 .. 0, 'halt'] ] :

but the numbering of the events does not appear to be consistent. The first time I run the simulation I get:

Warning, cannot evaluate the solution further left of -38.078909, event #2 triggered a halt

The second time I get this:

Warning, cannot evaluate the solution further left of -38.078909, event #4 triggered a halt

and then #6, and so on. For what is obviously the same event. I guess I may need to use eventclear before each simulation, but my earlier attempts failed. I will probably need to think about this some more, but in the meantime I tried another approach.

    for i to n do
        try
            sol := dsol(endpoint) ;
            if abs(rhs(rhs(sol('last')[1]))) >= abs(10) then 
                break ;
            else
                ln(0); # forcing an exception
            end if ;
        catch:
            ini1 := whatever
            dsol('initial'=ini1) ; # re-initialize dsolve
        end try ;
    end do ;
    ini1 ; # return modified initial conditions
    end proc :

In the above I create an error that will be caught by catch conditional upon dsolve not going "far enough", here the value abs(10).

A self-contained portion of my simulations is attached for reference, if anyone is curious about this. There are still things I need to fix. To do: It would be nice if I could be more specific about what to do when certain events trigger. I probably should write the events like this, and find a way to consistently keep track of them:
events = [ [r(t) = -1, 'halt'], [r(t) = 3/40, 'halt'], [u(t) = -5, 'halt'], [u(t) = 0, 'halt'] ] :

EDIT 1: I have uploaded an updated version of my simulations in progress. I did manage to use event triggers in the loop. At this point this scheme has only managed to compute initial conditions and trajectories for a fraction of the points of interest, but I do hope that further tweaking with the randomizing scheme or the digits or something will be made to work...

EDIT 2: Got it to work, at last! I had a number of problems in my code. One mistake was that I had augmented the procedure to take a "seed" as input, in order to be able to replicate future simulations exactly. But I had set randomize() in such a way that it was using the same seed for every trial I was running, so that my procedure was not random at all. Another problem I had was that I had set one of the events to trigger too early, forcing an exception and discarding trajectories that should otherwise have been accepted (this mistake came from the fact that the trajectory undergoes a sort of "bifurcation", changing direction somewhere near my 26th trajectory). There were one or two other problems that no-one could possibly be interested in. The bottom line is that it's been fixed and works as expected. Surely inefficiencies and awkward bits of coding remain...

A big thank you to my mentors at mapleprimes!

DynamicsMapleprimes2.mw

Preben, this is fantastic! This is beyond my coding ability and I would never have managed without your help. I have used the _Env_in_maplet:=true; assignment before without any problems. This and all the other help from you, pagan, acer has been very helpful. I've learned to beware of colons, to read from left to write, to unprotect and reprotect procedures, to try and to catch (perchance to catch). Many thanks to you all.

Preben, this is fantastic! This is beyond my coding ability and I would never have managed without your help. I have used the _Env_in_maplet:=true; assignment before without any problems. This and all the other help from you, pagan, acer has been very helpful. I've learned to beware of colons, to read from left to write, to unprotect and reprotect procedures, to try and to catch (perchance to catch). Many thanks to you all.

@Preben, For my limited needs, I think the first construction would be good enough:

   catch "cannot evaluate the solution further right of %1, probably a singularity","cannot evaluate the solution further left of %1, probably a singularity":

your suggestion of saving the error message returned by lastexception[2] is nice. I wonder, is there a way to do something similar for warnings? warnings do not produce an exception (if I understand correctly) and would not be caught by lastexception, but is there a way to parse the warning message and search for the word "singularity" in it? I guess that would not involve try/catch anymore but a simple if then statement. I could use this construct to distinguish an error message from a warning (with odeplot singularities cause warnings not errors, as noted above, events also cause warnings). Thanks.

@Preben, For my limited needs, I think the first construction would be good enough:

   catch "cannot evaluate the solution further right of %1, probably a singularity","cannot evaluate the solution further left of %1, probably a singularity":

your suggestion of saving the error message returned by lastexception[2] is nice. I wonder, is there a way to do something similar for warnings? warnings do not produce an exception (if I understand correctly) and would not be caught by lastexception, but is there a way to parse the warning message and search for the word "singularity" in it? I guess that would not involve try/catch anymore but a simple if then statement. I could use this construct to distinguish an error message from a warning (with odeplot singularities cause warnings not errors, as noted above, events also cause warnings). Thanks.

@pagan
@Preben Alsholm 

Thanks a lot for your explanations. The help files could definitely be clearer.

This is misleading: "The exception object that corresponds to the exception is compared against each catchString in turn until a match is found."

The comparison is made from left to right, but only starting from after: Error, (in unknown)

of

Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

In particular, the following wouldn't work:

try
    sol(1);
    print("tried");
catch "Error":
    print("caught");
end try;
Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

@pagan
@Preben Alsholm 

Thanks a lot for your explanations. The help files could definitely be clearer.

This is misleading: "The exception object that corresponds to the exception is compared against each catchString in turn until a match is found."

The comparison is made from left to right, but only starting from after: Error, (in unknown)

of

Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

In particular, the following wouldn't work:

try
    sol(1);
    print("tried");
catch "Error":
    print("caught");
end try;
Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

@Preben Alsholm 

I'm sorry it's taking me so long to understand this. I refer to your first example above

http://www.mapleprimes.com/questions/134162-Procedure-To-Modify-Initial-Conditions-In-Dsolve#comment134169.

Here is the ERROR message:

Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

Consider three possible ways to "catch" the error

• catch:  
• catch "cannot evaluate":
• catch "singularity":

(If I understand correctly) The first one will catch any ERROR (but not warnings), no matter what the error message is.

(If I understand correctly) The second one will catch any ERROR that has the error message "cannot evaluate".

And here I don't understand: Isn't the third example supposed to work in this case? It doesn't, but I don't see anything in the help files to suggest that it wouldn't.

The help pages state "The exception object that corresponds to the exception is compared against each catchString in turn until a match is found."

Well now, the third case does indeed produce an error message. The error message does have the word "singularity" in its strings. So wouldn't that be a "match" that ought to be found? But while catch: works catch "singularity" does not work.

What am I misunderstanding here?

Thanks!

http://www.maplesoft.com/support/help/Maple/view.aspx?path=try

@Preben Alsholm 

I'm sorry it's taking me so long to understand this. I refer to your first example above

http://www.mapleprimes.com/questions/134162-Procedure-To-Modify-Initial-Conditions-In-Dsolve#comment134169.

Here is the ERROR message:

Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

Consider three possible ways to "catch" the error

• catch:  
• catch "cannot evaluate":
• catch "singularity":

(If I understand correctly) The first one will catch any ERROR (but not warnings), no matter what the error message is.

(If I understand correctly) The second one will catch any ERROR that has the error message "cannot evaluate".

And here I don't understand: Isn't the third example supposed to work in this case? It doesn't, but I don't see anything in the help files to suggest that it wouldn't.

The help pages state "The exception object that corresponds to the exception is compared against each catchString in turn until a match is found."

Well now, the third case does indeed produce an error message. The error message does have the word "singularity" in its strings. So wouldn't that be a "match" that ought to be found? But while catch: works catch "singularity" does not work.

What am I misunderstanding here?

Thanks!

http://www.maplesoft.com/support/help/Maple/view.aspx?path=try

Personally I use this access, where there is no summary.
http://www.mapleprimes.com/recent/

acer, actually I do intend to use events and eventstop to ensure the simulations don't stray too far off their intended path, so I will do just as you suggest:

"Your final code could do both: check the eventstop and trap errors using try..catch."

acer and preben,

it would be great if try/catch could also catch warnings, with maybe a specific syntax like catch-warnings and catch-errors or something.  In my earlier posts I copy-pasted this message:

Warning, cannot evaluate the solution further left of -.35923730e-2, probably a singularity

This is a warning message about a singularity.

Further down, I copy-pasted the following error message:

Error, (in unknown) cannot evaluate the solution further right of .99999999, probably a singularity

This is an error message about a singularity.

Presumably try/catch will catch the latter but not the former. I'm not sure now why I got different messages, a warning here but an error there, I would need to carefully retrace my steps (most likely there was a call to dsolve here but a call to odeplot there, but I'm not certain), but there isn't a great urgency to find out the reasons in the light of your comment Preben: it is clear that various Maple routines are not in sync when it comes to throwing up warnings or errors. The way I have it set up now it throws up errors and gets caught by try/catch, which is what I want.

When I read the help file I took the word "exception" to mean something like "warning" but upon rereading I see that it might as well be a synonym for "error". Not sure if there are any differences between an exception and an error...