So here are my first impressions.

1. acer's suggestion: events = [[diff(y(t), t), 'halt']]
   
   Error, (in f) invalid input: diff received HFloat(0.0), which is not valid for its 2nd argument
   
   Not sure what's going on here. I've had no problem with acer's example. It seems to mean that the value of y(t) is so small that dsolve can't compute the derivative, or something like that. Oh well, never mind, as the second method works. Besides, the drawback of this approach, as noted, is that it cannot combine with the "compile" option.

2. Allan's suggestion: events = [[rhs(sys[2]), 'halt']], where sys denotes my ode system and sys[2] denotes the variable of interest, e.g. y(t), and thus rhs(sys[2]) gives the right-hand side of " diff(y(t), t) = some complicated and ill-behaved function of x(t),y(t),z(t) "
   
   This seems to work. I am surprised that it doesn't seem to slow down computations. I expected this approach to be so inefficient that I hadn't even bothered to try it. So much for my intuition. This method can be used with the "compile" option, so that's a plus.

So here are my first impressions.

1. acer's suggestion: events = [[diff(y(t), t), 'halt']]
   
   Error, (in f) invalid input: diff received HFloat(0.0), which is not valid for its 2nd argument
   
   Not sure what's going on here. I've had no problem with acer's example. It seems to mean that the value of y(t) is so small that dsolve can't compute the derivative, or something like that. Oh well, never mind, as the second method works. Besides, the drawback of this approach, as noted, is that it cannot combine with the "compile" option.

2. Allan's suggestion: events = [[rhs(sys[2]), 'halt']], where sys denotes my ode system and sys[2] denotes the variable of interest, e.g. y(t), and thus rhs(sys[2]) gives the right-hand side of " diff(y(t), t) = some complicated and ill-behaved function of x(t),y(t),z(t) "
   
   This seems to work. I am surprised that it doesn't seem to slow down computations. I expected this approach to be so inefficient that I hadn't even bothered to try it. So much for my intuition. This method can be used with the "compile" option, so that's a plus.

And wouldn't it be nice if you could just "toggle" by clicking on a button and all the 2D input would be converted to 1D input instantly (or within a few seconds) ?

Would that be feasible?

And wouldn't it be nice if you could just "toggle" by clicking on a button and all the 2D input would be converted to 1D input instantly (or within a few seconds) ?

Would that be feasible?

sounds like your x and y are coordinates, in which case you just need to max,min over the y coordinate, right?

It looks like a singularity, like the solver gave up, but it's not, it's a feature of the dynamics of a slow-fast system (think of the crazy things the Lorenz system does, for instance). On a different time scale, the change looks more smooth. It's common to analyze these systems by changing the time scale in the region where the system changes dramatically, but to do that you need to know where/when the system moves from the slow time scale to the fast one. I was hoping to use the information of the events option to detect the region where the sudden change occurs (to find the value of q at which the change starts). (there is specialized software for these systems, but I was hoping to be able to do it on the fly with Maple)

EDIT : the plot shows several trajectories of the system of ODEs, for different initial conditions (starting at time 0 and running time backwards towards negative values).

It looks like a singularity, like the solver gave up, but it's not, it's a feature of the dynamics of a slow-fast system (think of the crazy things the Lorenz system does, for instance). On a different time scale, the change looks more smooth. It's common to analyze these systems by changing the time scale in the region where the system changes dramatically, but to do that you need to know where/when the system moves from the slow time scale to the fast one. I was hoping to use the information of the events option to detect the region where the sudden change occurs (to find the value of q at which the change starts). (there is specialized software for these systems, but I was hoping to be able to do it on the fly with Maple)

EDIT : the plot shows several trajectories of the system of ODEs, for different initial conditions (starting at time 0 and running time backwards towards negative values).

Preben, Allan, acer, many thanks for your suggestions, you are very helpful.

1. Preben, your suggestion: events = [[[diff(y(t),t),y(t)<0], halt]]:
   Thanks for the clarification. Now I understand that the extra brackets were there to set up the conditioning. That's something that had me confused. In my problem, as it happens, I do not know the value of y(t) for which the derivative may change sign, hence I cannot condition in this way.
2. Acer, your suggestion: events = [[diff(y(t), t), halt]]:
   This is one of the syntaxes I had tried, but it wasn't working. Now I know why: I had the "compile" option on, and apparently it is incompatible with this form of event, hence I was getting the error message:

   Error, (in dsolve/numeric/SC/preproc) builtin function diff is not supported

3. Acer, well it's true that the reason why I was looking for a condition like diff(y(t),t)<0 rather than diff(y(t),t)=0 was that I wasn't sure if the solver would detect the flat portion of the curve, while the change in slope should be obvious. The picture below shows the abruptness of the change I am trying to detect. I am still to experiment to see if your approach will work. Now that I know that the "compile" option was interfering, it will be easier to get things done. This will have to wait tomorrow however.
   
   
4. Allan, your suggestion: events=[[sin(t),halt]]):
   Thanks for your suggestion. In your example, it is quite natural. I didn't want to go down that road because the expression on the right-hand side of diff(y(t),t) is badly behaved and I was afraid it might slow down computations. I figured that since dsolve already knows the value of diff(y(t),t) it would be efficient to condition on it, while it will not recognize the right-hand side of diff(y(t),t) as what it is and will have to recompute what it has already computed. I will experiment with this nevertheless.
5. Allan, one of the difficulties I had with the help page was that the simple intuitive examples I was trying weren't working because I had the "compile" option on. So, naturally, it would be useful to have a warning about it in the help page, specifically quoting the error message above. Your example with the [[sin(t),halt]] event is very helpful, I think it ought to be added to the help page. This help page needs more examples, really. Once you know how to use events option, the help page becomes a lot clearer... but the opposite would be better!

Thanks a lot, I will experiment with your suggestions and get back to you if I have further difficulties. Below the change I would like dsolve to sound a warning about:

Preben, Allan, acer, many thanks for your suggestions, you are very helpful.

1. Preben, your suggestion: events = [[[diff(y(t),t),y(t)<0], halt]]:
   Thanks for the clarification. Now I understand that the extra brackets were there to set up the conditioning. That's something that had me confused. In my problem, as it happens, I do not know the value of y(t) for which the derivative may change sign, hence I cannot condition in this way.
2. Acer, your suggestion: events = [[diff(y(t), t), halt]]:
   This is one of the syntaxes I had tried, but it wasn't working. Now I know why: I had the "compile" option on, and apparently it is incompatible with this form of event, hence I was getting the error message:

   Error, (in dsolve/numeric/SC/preproc) builtin function diff is not supported

3. Acer, well it's true that the reason why I was looking for a condition like diff(y(t),t)<0 rather than diff(y(t),t)=0 was that I wasn't sure if the solver would detect the flat portion of the curve, while the change in slope should be obvious. The picture below shows the abruptness of the change I am trying to detect. I am still to experiment to see if your approach will work. Now that I know that the "compile" option was interfering, it will be easier to get things done. This will have to wait tomorrow however.
   
   
4. Allan, your suggestion: events=[[sin(t),halt]]):
   Thanks for your suggestion. In your example, it is quite natural. I didn't want to go down that road because the expression on the right-hand side of diff(y(t),t) is badly behaved and I was afraid it might slow down computations. I figured that since dsolve already knows the value of diff(y(t),t) it would be efficient to condition on it, while it will not recognize the right-hand side of diff(y(t),t) as what it is and will have to recompute what it has already computed. I will experiment with this nevertheless.
5. Allan, one of the difficulties I had with the help page was that the simple intuitive examples I was trying weren't working because I had the "compile" option on. So, naturally, it would be useful to have a warning about it in the help page, specifically quoting the error message above. Your example with the [[sin(t),halt]] event is very helpful, I think it ought to be added to the help page. This help page needs more examples, really. Once you know how to use events option, the help page becomes a lot clearer... but the opposite would be better!

Thanks a lot, I will experiment with your suggestions and get back to you if I have further difficulties. Below the change I would like dsolve to sound a warning about:

@Preben Alsholm 

very strange, it displays fine here too on Maple 15 Standard (Windows), and I am unable to reproduce the behaviour. As I saved the plot by right-clicking, could it be that an awkward clicking move resulted in this? I wouldn't make much of it, it displays correctly and saves correctly now.

@Preben Alsholm 

very strange, it displays fine here too on Maple 15 Standard (Windows), and I am unable to reproduce the behaviour. As I saved the plot by right-clicking, could it be that an awkward clicking move resulted in this? I wouldn't make much of it, it displays correctly and saves correctly now.

@Preben Alsholm 

Nice one! here's the result:

@Preben Alsholm 

Nice one! here's the result:

Further analysis of the system revealed a condition on the parameters necessary for stability. Roughly speaking, this condition arises when one "plugs in" the center manifold reduction back into the original system. I hadn't seen it. All this is very new to me (and quite frankly I don't even know if I'm doing it correctly). Once this condition is imposed, all the simulated trajectories converge (i.e. the red-colored steady states are outside the stable range). I have thus resolved the problem I had with the simulations --- they did not converge because they do not converge.

There remains the issue of the sharp turn that q(t) makes as it approaches the steady state. (as seen here http://www.mapleprimes.com/view.aspx?sf=124914/419404/q10a.jpg). Is this "kink" a non-removable singularity or a manifestation of the slow-fast nature of the system?

This "kink" is present on one side of the steady-state points only. The bit of the trajectory where q(t) declines towards its steady-state value, (following a long flat segment) is, visually speaking, in "close" agreement with the center manifold approximation, as would be expected if my analysis is correct.The sharp turn from flat to downward-sloping takes very little time, this would be a manifestation of the "fast" in slow-fast...

(I've read a few introductions to slow-fast systems, but I can't say that I understand it well at all)

I was unable to upload the animated gifs posted above (they were too large) and therefore hosted them on an outside website. Do feel free to make local copies of the images and direct my links to the local copies, so that the images will be accessible even if my website is down. Thanks.