In the history of an evolving system there may be changes that aren’t smooth, we will call these occurrences ‘events’.
For example, it’s an event in a simulation of motion of a basketball when the ball bounces off the floor. A bounce can be implemented as a reversal of the direction of velocity. A condition can be set up specifying that if the ball is no longer above the floor it must have hit the floor, it must have bounced, and the ball must subsequently be moving in the opposite direction. If the height of the floor is defined as z=0, then when the value of z becomes smaller than 0 the ball’s velocity must be reversed.
However, that is not sufficient. The simulation proceeds with time increments so when the condition (z < 0) is met the ball will in fact be in an, shall we say, illegal position. To handle the bounce correctly the moment in time that the ball makes contact with the ground must be determined exactly (which the ODE solver cannot do), and the way that the bounce proceeds must be handled in a physically realistic way. After that the simulation can return to the ODE’s for the subsequent evolution.
EJS event handling determines the point in time of the event to within a specified tolerance. Starting in EJS version 4.2, if you leave the tolerance field blank, the same value as the solver’s absolute tolerance will be used for it.
The event editor
Types of events supported by EJS
EJS supports three types of events:
From the three events, the first one, State event, is the more powerful (and perhaps a bit more elaborated to specify), because is the only one that allows for consecutive events, that is an event that triggers a second event, which in turn triggers a third event,… For the other two types of events EJS assumes that the events are separated conveniently. More precisely, after an event takes place, the system will always evolve so that the given quantity is bigger than the tolerance specified for event detection before any further crossing takes place.
Specifying an Event
The event editor’s fop row allows you to specify the type of event, the number of iterations you want to allow for finding the exact moment when the quantity equals zero (up to the precision specified by the tolerance), and the method for finding this point. The Bisection method may be safer, but slower than Secant. Just try to see which one works best.
The second row allows you to enter the tolerance with which you can find the crossing instant. Because this is a numerical process, the exact point of zero crossing can only be found up to a given tolerance. This is the value you need to enter. A default value of 1.0e-5 for states ranging in the vicinity of [0,1] is just fine.
The Zero Condition is a method that returns the quantity whose zero value signals the event. The method can be as simple or as complicated as required, and is your complete responsibility!
The Action editor is a Java method that applies the changes to the state that you want to apply when the event takes places. If the state is a State Event, make sure this brings the state to a point where it will evolve to make the Zero function positive. If a Zero crossing or Positive crossing event, make sure the state is such that it will separate from zero (more than the event tolerance) before crossing zero again.
The End step at event indicates EJS if you want the ODE step to end if an event is found or not. This may be necessary if you want to visualize the state at the event instant of time, for instance.
The Comment field is just a text field for documentation purposes.
The Zeno effect action button brings an editor where you can specify what to do if the Zeno effect appears. This effect happens when the system triggers an increasing number of events in a decreasing interval of time, thus bringing the system to an effective halt down. EJS can detect this situation and, if you write code for this case, allow you to avoid the simulation from hanging. In this same bottom row, you can instruct EJS to check for possible events at small steps in time, smaller that the ODE increment. This may be needed if your state evolves so rapidly that a zero crossing may be skipped because the Zero Condition quantity quickly becomes negative and positive again. Stating a small value for this event checking step will allow you to detect those situations.