New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify countdown clock ticks #1560
Clarify countdown clock ticks #1560
Conversation
@PTaeuberDS : I think you are misunderstanding the entire mechanism. I reread the quotes you cite and those fit to what we are trying to say. Note that the reason for being in Event Mode will in most cases be a different clock than the one raised during this Event Mode (or Step Mode, Clock Activation Mode, Continuous Time Mode). Could you re-read the sections to see if that makes more sense now? |
@andreas-junghanns I am looking from the point of view of Scheduled Execution. The mechanism is clear to me. Maybe there are some differences for ME and CS that I do not know yet. However, this PR aims at a specific inconsistency in the definition of countdown clock ticks. The changes affect mainly SE parts of the spec. |
@andreas-junghanns I added most of our discussed points. Regarding the intermediateUpdateTime parameter in fmi3CallbackIntermediateUpdate, I talked with @MBlesken and we came to the conclusion that it should be ignored for SE (as it is already mentioned in the document). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed another issue with the time-base of the getInterval() for the Intermediate Update Mode.
Web Design Meeting: We just realized that the callbackIntermediateUpdate function is a (useless) merger of two functionalities for CS and SE and we should split that up again to simplify the callback for both interface types. Andreas: I will provide a separate PR for this split. Patrick: let´s commit this PR first. |
The specification is unclear about the concrete time of a countdown clock tick.
Across the spec there are described two contradictory point of views:
Here are some quotes that state the first variant:
Section 2.2.9.4:
The parameter name
clocksTicked
of the fmi3CallbackIntermediateUpdate function implies that the countdown clock already has ticked.Here are some quotes that state the second variant:
Table 5. Overview of Clock types. - countdown clock:
Section 2.2.9 - countdown clocks - interval description:
Section 5.1.1:
Comment in the SE code example:
// ask FMU if countdown clock is about to tick
As the ticking of a countdown clock is not clearly defined this could lead to misunderstandings. To fix this, one of the variants must be chosen. The second variant is to prefer for the following reasons:
If the clock already had ticked before fmi3CallbackIntermediateUpdate is called by the FMU this would be a behavior of an output clock
An input clock is defined as follows (2.2.9.2):
Since the model partition is activated after the interval is run out, there must be a clock tick. If it already had ticked "inside the FMU" and the interval is >0 there would be no model partition activation for that clock tick, which is contradictory to the definition of input clocks.
So, I propose to use the second variant to unify the description of countdown clocks and to rename the fmi3CallbackIntermediateUpdate parameter
clocksTicked
toclockHandlingRequested
according to other parameters likeintermediateVariableSetRequested
.@andreas-junghanns @MBlesken Please review