Handle time events in model exchange example. #71
Conversation
…nto handle_time_events # Conflicts: # examples/model_exchange.c
@t-sommer , the Stairs model is not being used with the model exchange example that is shown in the standard. The new model exemplifies both state and time events, and how state events can affect the next time of time events. What concrete changes do you propose? We could replace the BouncingBall example, as the new example supersedes that one. |
|
I'll put the simulation loop in a separate file, so we can reuse it for all models. |
That sounds good! I guess you have access to this PR, right? I made sure all maintainers had access. |
|
Also note that the time event detection should still be exact, and not restricted to the fixed step size used by the solver in model exchange. I understand that one might wish to fix it to the step size used (as done in #99 ) as this facilitates output printing and all that, but it's wrong: time events occur at a specific time and not subject to the whims of the solver. If one wants to output at fixed intervals, then interpolation should be used. |
|
The same is true for root finding, but requires a variable step solver (e.g. CVode). |
I don't fully agree that these two are the same. With state events, we know don't know up front the time they occur (on this, both FMU and Importer agree), so it's ok to tolerate inaccuracies caused by step size. On time events, the FMU dictates when the next one should occur, and the Importer should do its best to get there. The implementation of timed event handling is also different than the state event handling (though state event handling supersedes time event handling, in a "killing a fly with a cannon" way). But I see the appeal of treating the two in the same way :) |
|
@clagms, with your permission I will merge this PR. |
All good with me! |
This fixes the problem exemplified in #70 and described in #72
@andreas-junghanns and @t-sommer, please note that this is a serious problem because this code is being given as an example in the FMI standard document.
It should now pass all the checks, though I had to restrict the new FMU to ME of FMI 3.0, because it is very difficult to get the correct reference behavior from FMPy (in the case of co-simulation), which is being used as ground truth.