This is simply due to the numerical solver you have chosen. If you take large enough steps (by setting stoptime=50 or similar), the code does not work properly since the guard will not be triggered by the high velocity (the velocity is high, but still not high enough to bounce back above surface level...).

I find the following works better since now there is a much lower risk of getting stuck below the surface (acceleration checked every time-step):

model BB

  parameter Real k = 0.825; //collision factor 

  parameter Real g = 9.81; 

  parameter Real v_min = 0.50; //min. speed 



  Real x(start = 1.5); //height 

  Real v; // speed 

  Boolean stopped;

equation 

  v = der(x);  //Integration of path 

  der(v) = if not stopped then -g else 0.0;

  when x <= 0.0 then

    stopped = abs(pre(v)) < v_min;

    reinit(v, if not stopped then -k * pre(v) else 0.0);

    reinit(x, 0.0);

  end when; 

end BB;

This issue is related to the intervals, where the solver checks for events.
The solver checks for events only at output points, so if you increase the
numberOfIntervals the model will work proper.

What really happens there, is that in the step where the Ball falls through
the ground the  solver misses that the speed was while the last step less
than 0.05, but at  the next output point the speed is again bigger then 0.05
and then the event don't occurs again and the Ball falls further.

But with the current trunk version your example work proper, since we now check in
every step of dassl for events. That means for the solver dassl the event that are found
depends on the step sizes done by dassl and not any more on the numberOfIntervals.

Of course, for the other solvers it depends still on the output intervals(numberOfIntervals).

so long.
Willi

Thank you very much for your answer !!! You saved me a lot of sleepless nights But what you changed is basicly that you increased v_min from 0.05 to 0.5 ?? Or do I miss anything else?

Thank you very much for your answers !!! You saved me a lot of sleepless nights   Solver issues are really annoying.

@sjoelund.se  What you changed is basicly that you increased v_min from 0.05 to 0.5 ?? Or do I miss anything else?

Oh, sorry I did that too. Should not matter (I hope). Too much copy-paste and fiddling around until it worked properly. Event-handling in Modelica is sometimes a little hard to get right. Luckily you don't need it (Bouncing-Ball level hard) very often...