Open henrikt-ma opened 1 year ago
Yes, event clocks seem to break many of the assumption. And I believe @christoff-buerger have used them in interesting ways, any insights?
Event clock behavior and their semantic -- as I would expect it -- is basically like ordinary event semantics. You can have arbitrary many events triggering the clock to tick throughout a single integration step; the events can happen at any point. And you might run into the very same issues as you can for events, like no-termination (e.g., an infinite number of ticks at a single time point caused by the respective event being triggered again and again), mutual dependent events, event-clocks whose clocked system computes something that in turn will trigger other event clocks (there is a hold in between of course, but that doesn't imply any delay delta(t) > 0), events whose order is undefined causing undefined behavior (two clocks ticking at the very same moment and their outputs are mutually dependent used to trigger them; think of flip-flops here and the forbidden state). But non of these problems is anything new; all of these exist for events -- they are inherent to the concept of events.
It is important to note, that dependencies between event clocks are always via a small continuous time subsystem (i.e., there is some hold sample), but such does not imply any decoupling in terms of time delays. The clocked partition evaluates in 0 time (doesn't need any time to compute) and the event of the clock can be triggered many times for a single time point; each time the clocked partition will evaluate and its holded outputs get a new value. Such output values can in turn influence the event-condition of the very clock computing them.
I really see no difference to ordinary events; in fact the events of event clocks are just ordinary events. There is no special semantic here. The events are even evaluated in the continuous time partition; it just happens that they trigger a clock to tick whose clocked partition then must be evaluated. No special magic here.
In that sense I do not understand what you propose @henrikt-ma.
@christoff-buerger, I'm afraid you missed the point of the issue. Please see the quoted parts of the specification that I don't think match the description you gave.
I believe it is well understood that the specification doesn't give a correct picture of how event clock partitions need to be handled. First, we have https://specification.modelica.org/master/synchronous-language-elements.html#S5.SS1.SSS1 which claims:
As I understand it, this is not actually the case, as event clocks might tick in any any turn of an event iteration. It seems to me that this is most naturally achieved by evaluating the event clock partitions after the continuous-time partition, generally in every turn of the event iteration. (Of course, one needs to ensure that
sample(…)
behaves correctly, but more on this below.) Further, it also seems clear that the same event clock may tick several times during an event iteration, which contradicts https://specification.modelica.org/master/synchronous-language-elements.html#rationale-for-clocked-semantics:The lack of clarity regarding evaluation of event clock partitions makes me wonder about the definition of clocked
sample(u, clock)
in https://specification.modelica.org/master/synchronous-language-elements.html#modelica:clocked-sample:Is it the usual mathematical left limit which is meant, or is it the left limit in the sense of
pre
, https://specification.modelica.org/master/operators-and-expressions.html#modelica:pre?