Ambiguous relationship between clocks attribute and dependencies for clocked variables in ModelStructure

[Tc-Fast]

Section 2.2 states:

Declaring a variable as clocked variable using the clocks attribute specifies a dependency too, but also declares that such a clocked variable can only be accessed when one of the referenced Clocks is active.

Section 2.4 (note in the dependencies attribute description) states:

This means that all dependencies must be listed, also the dependencies of clocked variables on their clocks.

If a clocked variable explicitly declares dependencies in ModelStructure, must the value reference of its Clock be included in that dependencies list? Or does the clocks attribute already cover this?

[chrbertsch]

FMI Design Meeting: Additionally there needs to be a general clarification regarding the use of dependencies of clocked variables.

There might be dependencies that indicate the simultaneous handling of equation systems.
But in some cases one does not want to be the calcuation treated with algebraic loop detection, so no dependencies should be listed

[Tc-Fast]

Consider a simple gain FMU with input on Clock A and output on Clock B.
If you declare, that the output depends on input in dependencies, an importer doing algebraic loop detection would potentially flag a loop in a feedback connection — even if Clock A and Clock B never tick at the same time.
The loop can only actually form if both clocks are simultaneously active.
But nowhere in the standard does it say that importers should take clock assignments into account when evaluating loop candidates.

It is maybe fixable as follows:
clocks is purely an access gate — it says when a variable can be read or written, nothing more.
The associated clocks must not appear in dependencies of the respective variable.
Dependencies for clocked variables should only list variables with a genuine simultaneous algebraic relationship.
Importers should only treat a declared dependency as a loop candidate if the clocks of both sides can be simultaneously active — same clock, or clocks known to coincide.

[chrbertsch]

FMI Design Meeting:

Agreement: It does not make sense to list the clocks as dependencies, this information is already there.
Pierre: this seems to have rushed in with other changes ...
Pierre: the only thing we lose might be losing the dependencies ... But we did not specify anything about this.
Klaus: we also do not have a "clock" dependency kind