Skip to content

[synchronous semantics]Is it legitimate for sub-clock partitions to depend on each other #3776

@DengJH2023

Description

@DengJH2023

In synchronous semantics, is it legitimate for sub-clock partitions to depend on each other? For example, consider the following grammar:
model Test
Clock clk = Clock(0.1);
Real a = sample(time, clk);
Real sub1 = subSample(a, 2);
Real b = superSample(sub1, 2);
Real c = a + b;
end Test;
In this grammar, variables in the two sub-clock partitions depend on the values of variables in the other partition.
Some Modelica tools report errors or produce incorrect results when executing this grammar.

If this is legitimate, during simulation, we cannot compute all equations corresponding to one sub-clock partition before computing those of the other. How should this be handled in simulation?

My idea is: in the compiler backend, match all equations associated with a base clock, determine the solution direction, and mark which sub-clock partition each equation originates from.
Execute the equations within it in units of the base clock.Before executing each equation statement during simulation, first check whether its corresponding sub-clock is triggered.
However, with this approach, is there a scenario where we cannot confirm whether other sub-clocks should be triggered during the current base clock computation before the base clock (or sub-clocks with the same frequency as the base clock) starts computing?

Alternatively, is there a better handling method? The approach stated in MLS3.6—"use counters to handle sub-sampling scheduling"—is not a good idea,because this method generates a large number of temporary variables, and when the clock is not triggered, it is also necessary to determine whether all the equations need to be computed.

Looking forward to your opinion!

Metadata

Metadata

Assignees

No one assigned

    Labels

    clarificationSpecification of feature is unclear, but not incorrectclockedClocked parts of Modelica; synchronous and state-machines

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions