id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5462	Inaccurate simulation of systems with noEvent and saturations using the C runtime	Francesco Casella	Andreas Heuermann	"When signal saturations are modelled using {{{noEvent()}}}, the C runtime has some issues, as exemplified by the {{{Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator}}} model.

1. 

When simulating the model with OMEdit, some numerical errors are reported during the simulation, around some of the events. In fact, the simulation reaches {{{stopTime}}} successfully, but for some reason the final solver statistics and the end message ""The simulation finished successfully."" are not displayed. This should be corrected.

2. 

The testsuite reports a verification failure, see, e.g., the plot of [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator.diff.opAmp.out.v.html opAmp.out.v], which shows how the period of the OMC simulation is significantly shorter than the one of the reference plot.

The experiment annotation sets StopTime = 1, Tolerance = 1e-6, and Interval = 0.001. 

If the simulation is run with these parameters (as Jenkins does), the last commutation of {{{opAmp.out.v}}} takes place at time {{{0.975}}}, much earlier than the value of {{{0.9835}}} of the reference plot, which was computed by Dymola using the same parameters. 

If I now decrease the Interval to 0.0002, the last commutation takes place at time 0.9826, which is much closer to the reference plot. However, the precision of the location of time events shouldn't really depend so much on the reporting interval length, so there is probably something fishy going on here.

On the other hand, if I turn off Equidistant time grid off, and keep the tolerance to 1e-6, the last commutation takes place even earlier than with 0.001 communication interval, at time 0.97266. Only if I decrease the tolerance to 1e-10 do I get the last commutation to take place at time 0.9843, which is probably very close to the exact result, and is the same that I get with Dymola using the same settings.

Summing up, even with a fairly tight tolerance setting (1e-6), it seems that the actual choice of communication interval (or the absence thereof) has an excessivly high impact on the accuracy of the solution of a simple system (it is a first-order ODE) that has state events. On the other hand, Dymola (which basically uses the same ODE solver, DASSL) doesn't show such a dependency, which probably means there is something wrong with our implementation.

This is immediately apparent if you check the plots of [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator.diff.c.v.html c.v], which is the only state variable of the system. If you zoom in around time = 0.034, it is apparent how the OMC solution change direction at a value of -7.4, much earlier than the correct value of -7.5 which is shown by the reference solution.

It looks like the event is not triggered at the zero-crossing time, but rather at the previous step (or communication interval). This seems quite a serious issue for the simulation of systems that heavily depend on state events.

Karim, Andreas, Lennart, can you please have a look? "	defect	assigned	blocker	2.0.0	Run-time				Lennart Ochel Andreas Heuermann