Event clock partitions, event iteration, and sample

[henrikt-ma]

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:

… all base-clock partitions, see section 16.7.3, need not to be sorted with respect to each other. Instead, at an event instant, active base-clock partitions can be evaluated first (and once) in any order. Afterwards, the continuous-time partition is evaluated.

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:

6. Clocked equations are straightforward to optimize because they are evaluated exactly once at each an event instant.

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:

The operator returns a clocked variable that has clock as associated clock and has the value of the left limit of u when clock is active (that is the value of u just before the event of c is triggered).

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?

At an event instant, y(tMinus) is the value of y after the last event iteration at time instant t (see comment below).

[HansOlsson]

Yes, event clocks seem to break many of the assumption. And I believe @christoff-buerger have used them in interesting ways, any insights?

[christoff-buerger]

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.

[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.