Move Clock dependency info to attribute

[t-sommer]

fixes #1370

• Re-generated schema figures.

[andreas-junghanns]

@t-sommer : Is this ready for review? If not, can I help?

@TorstenBlochwitz : Can you have a look, please and comment? Do you remember why we originally chose to have a ModelStructure element and not add this as attribute to the Variable element as now proposed?

[KarlWernersson]

@andreas-junghanns
As far as I remember, the discussion was that both ways of of representing the information was valid and gave the same information. It ended up being a matter of preference on how to represent it. A vote was cast and it ended 2:1, it the small working group.

[t-sommer]

The schema figures still need to be regenerated.

[andreas-junghanns]

@andreas-junghanns
As far as I remember, the discussion was that both ways of of representing the information was valid and gave the same information. It ended up being a matter of preference on how to represent it. A vote was cast and it ended 2:1, it the small working group.

@t-sommer convinced me that this proposal might be a better way for these reasons:

• shorter lists are more human readable
• information is now more naturally aligned with other "Variable" information
• ModelStructure uses the other dependency direction for (most) other elements

@TorstenBlochwitz : Any strong arguments against?

[andreas-junghanns]

The schema figures still need to be regenerated.

Done.

[andreas-junghanns]

Ready for review?

[IZacharias]

I like the idea of putting the clock dependency back to the variables.

But why are we limiting this to discrete variables?
Especially in Scheduled Execution, we need the relationships to clocks not only for inputs and outputs, but also for parameters and local variables. Only in this way the master is able to generate optimal code. The master needs the information to decide on where to place the calls to the fmi3GetXXX() and fmi3SetXXX() functions.
Example: If a parameter is only needed for the calculation of exactly one model partition, updating its value, i.e. calling the fmi3SetXXX() function, is only necessary and meaningful before calling the fmi3ActivateModelPartition() function for the corresponding clock.

[KarlWernersson]

@IZacharias

But why are we limiting this to discrete variables?

Only discrete variables will change at a clock tick.
If it is continuous it cannot belong to the clock.

For fixed tunable and constant. These are set or retrieved independent of clock ticks.
You would only call set/get at initializatoinMode (possible event mode if you change tunable).
So is it really needed for optimizing that? Initialization is still done globally and not on specific clock partion.

But it could still have some use for model information to assign parameters to specific clock partitions, so as long as we forbid continuous I am ok to allow all others to be part of a clock.

[IZacharias]

@IZacharias

But why are we limiting this to discrete variables?

Only discrete variables will change at a clock tick.
If it is continuous it cannot belong to the clock.

For fixed tunable and constant. These are set or retrieved independent of clock ticks.
You would only call set/get at initializatoinMode (possible event mode if you change tunable).
So is it really needed for optimizing that? Initialization is still done globally and not on specific clock partion.

But it could still have some use for model information to assign parameters to specific clock partitions, so as long as we forbid continuous I am ok to allow all others to be part of a clock.

@KarlWernersson You're right, I probably didn't make that clear enough. My point is to allow it for tunable parameters, discrete inputs, discrete outputs, and discrete local variables. For fixed, constant, continuous it is not needed or makes no sense.

[chrbertsch]

Regular Design meeting:

let's merge it. @t-sommer will do so.

[IZacharias]

Only discrete variables can have this attribute.

We need the information also for tunable parameters, i.e. discrete variables and tunable parameters can have this attribute.