Clarify Clock terminology: use "Clock tick" for super dense time inst…#2107
Clarify Clock terminology: use "Clock tick" for super dense time inst…#2107Tc-Fast wants to merge 1 commit intomodelica:mainfrom
Conversation
…ant and "Clock activation" for the action of chaning it
chrbertsch
left a comment
There was a problem hiding this comment.
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>>. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
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:: |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
|
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! |
masoud-najafi
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
The time instant of the first clock activation
|
|
||
| |latexmath:[t_{i-1}] | ||
| |The previous time instant, when the Clock ticked. | ||
| |The previous Clock tick. |
There was a problem hiding this comment.
The previous clock activation instant
|
@Tc-Fast : should we not leave this open as draft PR until we solve the open clock related issues? |
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".