Improve the specification of fmi3GetInterval and interval qualifiers #2050
Conversation
PTaeuberDS
force-pushed
the
fixGetIntervalDescription
branch
from
227daca to
18448dd
Compare
PTaeuberDS
force-pushed
the
fixGetIntervalDescription
branch
from
bfec03e to
d7ce096
Compare
chrbertsch
requested review from
andreas-junghanns,
klausschuch,
masoud-najafi and
pmai
| |Generally, the time interval from the previous Clock tick to the current Clock tick. | ||
| An exception applies to a tunable Clock whose interval has just changed in <<EventMode>> or <<ClockActivationMode>>. | ||
| In this specific case, the new interval is relative to the time of the current <<EventMode>> or <<ClockActivationMode>>, not to the time of the previous Clock tick. | ||
|
|
There was a problem hiding this comment.
Would't it be more concise if we say: "The time interval from the current Clock tick to the next Clock tick, specified differently for the different Clock types." That would hold for Tunable clock too.
There was a problem hiding this comment.
No, it wouldn't. The interval of a tunable clock can change at any (event) time without the clock having ticked. So there is not necessarily a current clock tick.
|
I wonder if there is a way to visualize the tables? Any artifact has been created for these changes? |
@masoud-najafi : |
| The importer must use <<fmi3GetShift>> to retrieve the Clock shift in <<InitializationMode>>. | ||
|
|
||
| + | ||
| In both cases, when an interval changes, the new interval is relative to the time of the current <<EventMode>> or <<ClockActivationMode>>, not to the time of the previous Clock tick. |
There was a problem hiding this comment.
I'm not sure if I understand this correctly. Suppose the previous clock tick has been at time=T_k and the next tick will be at time=T_{k+1}=T_K+DT, where DT is the current interval of the clock. If an event happens at T_e where T_K< T_e <T_{k+1}, and at this time event the interval of the clock is changed by the importer to DT2, what would be the time of the next clock tick?
There was a problem hiding this comment.
In this case T_e + DT2, as the interval is defined from the current event time to the next clock tick.
| _Subsequent Clock ticks follow the general interval definition for periodic Clocks until the tunable interval changes again._ | ||
|
|
||
| ^|_(7)_ | ||
| |_In super state <<Initialized>>, for a changing Clock, <<fmi3IntervalChanged>> is returned if and only if the Clock has just ticked._ |
There was a problem hiding this comment.
I do not understand why you have extended this part to the superState . The GetInterval cannot return fmi3IntervalChanged in other state than EventMode.
|
|
||
| is a time-based Clock with a constant interval, except when <<intervalVariability>> = <<tunable>>, which indicates that the interval can change. |
There was a problem hiding this comment.
Minor remark:
I wouldn't use "when" in this context it might be confusing because when might indicate a certain time point.
"except for Clocks with <> = <>"
| [[fmi3IntervalUnchanged,`fmi3IntervalUnchanged`]] | ||
| * `fmi3IntervalUnchanged` is returned if a previous call to <<fmi3GetInterval>> already returned a value qualified with <<fmi3IntervalChanged>> which has not changed since. | ||
| * `fmi3IntervalUnchanged` is returned if a previous call to <<fmi3GetInterval>> already returned a value qualified with <<fmi3IntervalChanged>> which has not changed since, or if the FMU is not allowed to change the interval because it is meant to be set by the importer or already fixed for the simulation (e.g., the interval of a constant Clock). | ||
| In this case, <<intervals-get>> returns the old unchanged interval. |
There was a problem hiding this comment.
"old unchanged interval" relative to what time? The current time instant or the time instant when the qualifier for this clock was "fmi3IntervalChanged" the last time.
Shouldn't we change this to "has no meaning"?
| * `fmi3IntervalNotYetKnown` is returned for a <<countdown-aperiodic-clock,`countdown`>> Clock for which the next interval is not yet known. | ||
| This qualifier value can only be returned directly after the Clock was active and previous calls to <<fmi3GetInterval>> never returned <<fmi3IntervalChanged>> (nor <<fmi3IntervalUnchanged>>). | ||
| In Scheduled Execution this return value means that the corresponding model partition cannot be scheduled yet. | ||
| * `fmi3IntervalNotYetKnown` is returned for a <<countdown-aperiodic-clock,`countdown`>> Clock for which the next interval is not yet known. |
There was a problem hiding this comment.
we use "known" for 2 different perspectives here:
- the FMU doesn't know it yet
- the importer doesn't know it yet and hence has to ask the FMU
Here it is option (1) but above it was option (2).
I suggest to distinguish between these two explicitly.
| This qualifier value can only be returned directly after the Clock was active and previous calls to <<fmi3GetInterval>> never returned <<fmi3IntervalChanged>> (nor <<fmi3IntervalUnchanged>>). | ||
| In Scheduled Execution this return value means that the corresponding model partition cannot be scheduled yet. | ||
| * `fmi3IntervalNotYetKnown` is returned for a <<countdown-aperiodic-clock,`countdown`>> Clock for which the next interval is not yet known. | ||
| This qualifier value can only be returned directly after the Clock was active and previous calls to <<fmi3GetInterval>> never returned <<fmi3IntervalChanged>> (nor <<fmi3IntervalUnchanged>>). |
There was a problem hiding this comment.
To me this reads like the clock cannot have an undefined interval at all anymore after it had an interval once, even after the clock was active already.
This is not what I would expect
5 participants
This pull request clarifies the definition and usage of Clock intervals, primarily by making fmi3GetInterval more flexible and explicitly defining its behavior in all situations.
Key Changes:
Resolves #2018