Supporting multi-clock discrete systems

[sharanry]

Currently, DiscreteSystem and ODESystem both support only single clock systems.

1. For multi-clock discrete transitions using the Difference operator in ODESystem, the plan is to have separate periodic callbacks for each set of synchronous discrete transitions. We could later extend this to a single customized discrete callback if the need arises.

2. In order to support multi-clock DiscreteSystems, we might need to group each set of the synchronous transitions and generate a separate function for each such group. We could then call each of these functions as a function of time (t) by an outer function. Is there a better way to do this?

3. It is also possible that each of these "clocks" starts at different times, I am not sure how common such scenarios are in practice. If we want to support these kinds of systems, we might need to add an extra field indicating the start time to the difference operator which defaults to 0. This start time could later be fetched while creating the periodic callback.

@ChrisRackauckas @YingboMa We have already discussed 1. Any thoughts on 2 and 3?

[ChrisRackauckas]

The actual hard thing about multi-clock is dependencies. If you have a clock at 3 and a clock at 5, and D(x) ~ y, D(y) ~ x, which one do you do first at 15? Is it an implicit system? I think we'd want to just error in that case for now.

[baggepinnen]

To what extent do DiscreteSystems appear in acausal contexts? For control-related purposes, the dependencies are given by the causal nature of discrete input/output systems.

Without having thought too much about it yet, I can imagine the following case

sensor reading -> controller (causal) --d2c--> physical system (acausal) --c2d--> sensor reading (loop closed)

Somewhere in this loop there would have to be a delay, would that resolve the dependency problem? Are there more complicated cases where a delay is not present? I recall simulink erroring with "error: algebraic loop" if the delay is not present.

[baggepinnen]

I'm dropping this paper link here for reference, it does a good job explaining the rationale for the new design of the Modelica clock module.
https://ep.liu.se/ecp/076/001/ecp12076001.pdf
"Fundamentals of Synchronous Control in Modelica"

Some summarizing quotes below

This paper describes the fundamental synchronous language primitives introduced for increased correctness of control systems implementation. The approach is based on associating clocks to the variable types. Special operators are needed when accessing variables of another clock. This enables clock inference and increased correctness of the code since many more checks can be done during translation

However, the Modelica approach also uses multi-rate periodic clocks based on rational arithmetic introduced by (Forget et. al. 2008) ...

The boundaries between continuous-time equations and discrete-time equations are defined by the operators sample and
hold.

They introduce variable qualifier discrete and functions Clock, sample, hold, all time-varying variables appearing in equations that include discrete-time variables must be associated with the same clock (clock != sample rate).

This approach to identify the equations belonging to the same clock is called clock inference
and is a key element in the new approach.

They also mention (sec 2.6) that different clocks are not guaranteed to be synchronized unless exact rational numbers are used as clock rates.

---

@sharanry The scenario where different clocks start at different times is outlined in the paper, see sec 2.5. One case when it's used is when you want to make sure that some async calculation has had time to happen before you try to use the result. The alternative is that you wait for the result, but that introduces jitter (stochastic rate, bad for control), so you instead offset the clock rate enough that you know the result is available.

[ChrisRackauckas]

@YingboMa @baggepinnen this is done?

[baggepinnen]

Yeah, the rest of the work required have other issues tracking it, like

• Clocks TODO #1939