Add no further clock restriction

[andreas-junghanns]

No description provided.

[chrbertsch]

Shall merging this issue really close #1385 which goes beyond clocked variables?

[andreas-junghanns]

Since we do not understand what a design walkthrough would do more than what we did and since nobody else seems to be interested in doing whatever-needs-to-be-done, we think this is as much as can be expected to happen.
Of course, you (or anyone else) can disagree, but I would kindly ask to suggest exactly what and especially when that will be done.

[masoud-najafi]

The wording is not really clear for me. Does that mean that an input clock can depend on an output clock? If yes, if the output clock ticks, the dependent input clock should tick "synchronously"?

[andreas-junghanns]

The wording is not really clear for me. Does that mean that an input clock can depend on an output clock? If yes, if the output clock ticks, the dependent input clock should tick "synchronously"?

Not quite: Only if the output clock ticks, may this input clock tick.
We don´t know if this has practical applications, but according to @klausschuch - we should not forbit something just because we do not know what to use it for (as long as the mechanisms itself is clear).

[masoud-najafi]

Ok. Sorry, but I need to have clear mind about it. Then, there should be an "internal" dependency between the output clock and input clock and causes this "possible" tick?

[andreas-junghanns]

Ok. Sorry, but I need to have clear mind about it. Then, there should be an "internal" dependency between the output clock and input clock and causes this "possible" tick?

The question was, if input clocks could be a clocked variable on another clocks and if there are restrictions.
One could say, it only makes sense to have an input clock be a clocked variable of another input clock.
But why be so restrictive?
Therefore, we decided NOT to restrict clocked clocks.

[masoud-najafi]

But this would open the Pandora's box. Just suppose there is an output clock CO, and there is an input clock which is the clocked variable of CO. Similar to what we discussed last year, and finally it was not accepted and IntervalType of CountDown clock was introduced to disallow it. With this feature, CountDown Clock is no more needed, I can do it with this feature. I will check it anyway if everything is fine with this new feature.

[andreas-junghanns]

But this would open the Pandora's box. Just suppose there is an output clock CO, and there is an input clock which is the clocked variable of CO. Similar to what we discussed last year, and finally it was not accepted and IntervalType of CountDown clock was introduced to disallow it. With this feature, CountDown Clock is no more needed, I can do it with this feature. I will check it anyway if everything is fine with this new feature.

A countdown clock would allow scheduling ahead of time. This here is different, because the current output clocks can only be triggered.

[MBlesken]

@andreas-junghanns @masoud-najafi this contradicts "[Output Clocks are intended to enable an FMU to provide a trigger to the outside world, e.g. to a triggered input Clock of another FMU. Note, that if intended to activate model partitions or a Clock of the same FMU calling fmi3GetInterval for a countdown Clock and evaluating the qualifiers is recommended. An example is provided in Section 5.3.]". I would rather not have output clocks trigger input clocks of the same FMU but recommend to use countdown clocks instead.

[andreas-junghanns]

... and I think we all agree with your preference. The question here is: Should we restrict the standard to mandate our preference, or should we allow such "wired" usages? In our discussion we tend to follow the Klausian camp: "Why restrict a usage simply because we do not know what it is good for."

[MBlesken]

@andreas-junghanns ... No we're not discussing to restrict it. It is a recommendation. To be consistent within the standard we should not give an example that ignores the recommendation. That's all. Can we please adjust this?

[masoud-najafi]

Suppose that an input clock c1 that depends on another input/output clock c2, then is c2 sub-samples c1, or it indicates dependency of c2 on c1? It is not clear for me....

[andreas-junghanns]

@andreas-junghanns ... No we're not discussing to restrict it. It is a recommendation. To be consistent within the standard we should not give an example that ignores the recommendation. That's all. Can we please adjust this?

@MBlesken : I don´t understand: adjust what? The example? The text?

[andreas-junghanns]

Suppose that an input clock c1 that depends on another input/output clock c2, then is c2 sub-samples c1, or it indicates dependency of c2 on c1? It is not clear for me....

If c1 depends on c2, how can c2 be a sub-sample of c1? I do not understand your question?

[masoud-najafi]

Sorry, a mistake:
Suppose that an input clock c1 is clocked variable of another input/output clock c2, then c1 would subsample c2? or it indicates dependency of c1 on c2?

[andreas-junghanns]

Sorry, a mistake: Suppose that an input clock c1 is clocked variable of another input/output clock c2, then c1 would subsample c2? or it indicates dependency of c1 on c2?

Well, just go through the motions: if c1 is a clocked variable of c2, then c1 can only be accessed when c2 is active. That means c1 can only be a sub-sampling clock of c2. Depending on input or output, either the importer must observe this dependency or the FMU itself, respectively.

This seems pretty clear to me. Am I missing an open point or a contradiction?