Skip to content
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 the information flow of clocks #1944

Merged
merged 1 commit into from
May 15, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions docs/2_2_common_mechanisms.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -284,7 +284,9 @@ All variables are listed in <<modelDescription.xml>> as elements of `<fmiModelDe

They are identified with a unique handle called <<valueReference, value reference>>.

The attribute <<causality>> defines the direction of the information flow with respect to the FMU (e.g. <<input>>, <<output>>, <<parameter>>).
The attribute <<causality>> defines the direction of the information flow with respect to the FMU (e.g. <<input>>, <<output>>, <<parameter>>). +
For Clocks the <<causality>> indicates the information flow of the activation of the Clock. +
Only for triggered Clocks, the <<causality>> also indicates the information flow of the timing.

Variables, except Clocks, may be scalar or multi-dimensional arrays.
Clocks must always be scalar.
Expand Down Expand Up @@ -536,7 +538,11 @@ Input Clock::
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>>.
While the importer is the source of the actual Clock activations, the timing of the Clocks is defined by the FMU, either through the <<modelDescription.xml>> or calling <<fmi3GetInterval>>, or by another Clock connected to a <<triggered>> input Clock.

The importer is the source of the actual Clock activations of input Clocks.
For time-based input Clocks, the timing is defined by the FMU, either through the <<modelDescription.xml>> or by the importer calling <<fmi3GetInterval>>.
For <<triggered>> input clocks, the timing is determined by the importer.
_[The timing could be given by a triggered output Clock, or a time-based input Clock of a connected FMU, or any other source.]_

Output Clock::
[[outputClock, `output Clock`]]
Expand Down
7 changes: 5 additions & 2 deletions docs/2_4_common_schema.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -965,8 +965,11 @@ If a <<structuralParameter,`structural parameter`>> is referenced in <<Dimension
The `min` attribute might still be 0.

The default of <<causality>> is <<local>>. +
A continuous-time <<state>> or an event indicator must have <<causality>> = <<local>> or <<output>>, see also <<ModelStructure>>. +
The causality of variables of type <<Clock>> must be either <<input>>, <<output>> or <<local>>.
A continuous-time <<state>> or an event indicator must have <<causality>> = <<local>> or <<output>>, see also <<ModelStructure>>.

The causality of variables of type <<Clock>> must be either <<input>>, <<output>> or <<local>>. +
For Clocks the <<causality>> indicates the information flow of the activation of the Clock. +
Only for triggered Clocks, the <<causality>> also indicates the information flow of the timing.

|`variability`
|
Expand Down
Loading