Skip to content

Clarify Clock terminology: use "Clock tick" for super dense time inst…#2107

Draft
Tc-Fast wants to merge 1 commit intomodelica:mainfrom
Tc-Fast:clock_ticks
Draft

Clarify Clock terminology: use "Clock tick" for super dense time inst…#2107
Tc-Fast wants to merge 1 commit intomodelica:mainfrom
Tc-Fast:clock_ticks

Conversation

@Tc-Fast
Copy link
Copy Markdown
Contributor

@Tc-Fast Tc-Fast commented Jan 30, 2026

Closes #2084

Use "Clock tick" for the super dense time instant of the clock activation.
Use "Clock activation" for the action of changing the clock.
Add definition for "Clock tick" and "Clock activation".

…ant and "Clock activation" for the action of chaning it
Copy link
Copy Markdown
Collaborator

@chrbertsch chrbertsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to better distinguish of the "Clock tick" usage in ME+CS on the on hand and SE on the other.

(Reminder: "clock ticks" are also used in image https://fmi-standard.org/docs/3.0.2/images/se_example.svg)

is a variable of type Clock with <<causality>> = <<input>>.
In Model Exchange and Co-Simulation, when input Clocks tick, the importer will activate the input Clocks using <<fmi3SetClock>>.
In Scheduled Execution, when input Clocks tick, the importer will activate the associated model partitions (but not the input Clocks) using <<fmi3ActivateModelPartition>>.
In Model Exchange and Co-Simulation, when input Clocks are activated, the importer will activate the input Clocks using <<fmi3SetClock>>.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In Model Exchange and Co-Simulation, when input Clocks are activated, the importer will activate the input Clocks using <<fmi3SetClock>>.
In Model Exchange and Co-Simulation, input Clocks are activated by the the importer using <<fmi3SetClock>>.

They are restricted to being scalar variables.

Clock tick::
A super-dense time instant at which a Clock is active (i.e., the Clock's activation state is `fmi3ClockActive`). A Clock tick denotes the precise time point — including its super-dense ordering — during which clocked variables and the associated model partition may be evaluated.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only true for ME and CS, in SE the Clocks do not get activated, there is also no event mode and super dense time does not not used there ...

I think for SE we should better between "simulation time" (which is also used as "ActivationTime" and "wall clock time" (which is e.g. the time displayed in the time axis of "https://fmi-standard.org/docs/3.0.2/images/se_example.svg"
I suggest to define:
"Within Scheduled Execution, a "clock tick" signifies that its associated model partition is ready for execution at a specific simulation time and is consequently added to the scheduling queue for activation (with that simulation time as activationTime)".

Clock tick::
A super-dense time instant at which a Clock is active (i.e., the Clock's activation state is `fmi3ClockActive`). A Clock tick denotes the precise time point — including its super-dense ordering — during which clocked variables and the associated model partition may be evaluated.

Clock activation::
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Clock activation::
Clock activation (only for ME and CS)::

The FMU may request to schedule another model partition even while currently a model partition is being executed.

In case more than one Clock ticks at the same time instant, the scheduler needs a priority to define the activation sequence of the associated model partitions.
In case more than one Clock is activated at the same time instant, the scheduler needs a priority to define the activation sequence of the associated model partitions.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In case more than one Clock is activated at the same time instant, the scheduler needs a priority to define the activation sequence of the associated model partitions.
In case more than one Clocks ticks correspond to the same simulation time instant, the scheduler needs a priority to define the activation sequence of the associated model partitions.

@chrbertsch chrbertsch requested review from clagms and pmai January 31, 2026 20:46
@clagms
Copy link
Copy Markdown
Collaborator

clagms commented Feb 2, 2026

Could we wait with this a bit more so I can better understand the issue. I feel that the meaning of tick is well defined for the Synchronous Clocks interface. I just need to get more info in #2084 to see if this is an inconsistency in the definition of clocks, or just an inconsistency between Scheduled Execution and Synchronous Clocks... the two are very difference usages of clocks, so we might just as well clarify that difference between rather than possibly confuse the implementers of SC. Thanks!

Copy link
Copy Markdown
Collaborator

@masoud-najafi masoud-najafi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the remark about PR 2050 and getInterval()

<<fmi3ActivateModelPartition>> in <<ClockActivationMode>>,
<<fmi3GetInterval>> in <<InitializationMode>>,
<<fmi3GetInterval>> in both <<EventMode>> and <<ClockActivationMode>> if and only if this Clock ticked
<<fmi3GetInterval>> in both <<EventMode>> and <<ClockActivationMode>> if and only if this Clock was activated
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, in PR #2050 , we said getInterval may be called in any event mode and may affect non-active clock intervals too.

|===
|latexmath:[t_0]
|The time instant when the Clock ticks the first time.
|The time instant of the first Clock tick.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The time instant of the first clock activation


|latexmath:[t_{i-1}]
|The previous time instant, when the Clock ticked.
|The previous Clock tick.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous clock activation instant

@Tc-Fast Tc-Fast closed this Feb 3, 2026
@Tc-Fast Tc-Fast deleted the clock_ticks branch February 3, 2026 07:49
@Tc-Fast Tc-Fast restored the clock_ticks branch February 3, 2026 07:49
@chrbertsch
Copy link
Copy Markdown
Collaborator

@Tc-Fast : should we not leave this open as draft PR until we solve the open clock related issues?

@chrbertsch chrbertsch reopened this Feb 3, 2026
@chrbertsch chrbertsch marked this pull request as draft February 3, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define "clock tick" before it is first used

4 participants