Interval and shift values in modelDescription.xml for Clock arrays

[paulfilip]

I haven't found any clear explanation regarding the attributes intervalDecimal and shiftDecimal in the XML description file for a multi-dimension Clock variable. In figure 29 (Clock element) from Ch. 2.4.7, a Clock element may have the previous mentioned attributes, but they are explicitly a float value (I understand from this that only one value is allowed). However, functions fmi3GetIntervalDecimal, fmi3SetIntervalDecimal have 2 different arguments, nValueReferences and nIntervals, which I guess can used to specify different intervals for elements from the same variable. In this case, shouldn't intervalDecimal or shiftDecimal attributes be built in the same way as start attribute (where if only one value is present, then all elements of an array have the same value and if not, each value is assigned to an element) ? Or an array of clocks should have the same shift and interval values?

[chrbertsch]

Regular Design Webmeeting:

Pierre: I think the problem exists, we should change the XML schema. It should be the start attribute.
Klaus: we should also check the API
Pierre: this applies not only to the intervalDecimal and shiftDecimal attributes, but also to other atttributes. For some of them we do not want them to be lists, because perhaps we want some of them to be identical across an array of clocks.
E.g. there is the interval enumeration. Probably we do not want to make this different for different array
Pierre: the API-functions support multiple values. At least those corresponding to them should be made to lists.

@masoud-najafi will check the clock attributes and comment this ticket
Then Clock experts should comment
@pmai could make changes to the the XML schema

[masoud-najafi]

A variable of type Clock have the several clock specific attributes in the XML. "supportsFraction" and "interval" attributes define the behavior of the clock variable in whole, so their value should be unique, i.e., a single value should be provided.
On the other hand, the rest of attributes, i.e., "canBeDeactivated", "priority", "intervalDecimal", "shiftDecimal", "resolution", "intervalCounter", "shiftCounter" may have single value or array values. Similar to other array variables, if the Clock variable is multi-dimensional and a single value is provided, the provided value will be used for all elements of the clock.

[chrbertsch]

@pmai : could you please create a PR? Thanks!

[andreas-junghanns]

@pmai : will you be able to build a PR?

[PTaeuberDS]

For me, the specification is unclear about how to handle clock arrays at all.

The specification says:
"Each Clock k induces a discrete system."

How can this be mapped to clock arrays?

Does each clock array element induce its own discrete system (model partition)? Assigning this clock to a variable (attribute clocks), would mean the variable is assigned to multiple model partitions. So in this case the only use case for clock arrays are variables assigned to multiple model partitions, which is a modeling concept that we do not want to encourage. Also, "Each Clock k induces a discrete system." would be incorrect as each clock can induce multiple model partitions.

Or does it mean a clock array induces one model partition. Then this clock/model partition is activated with several intervals. Is that needed/wanted? fmi3GetInterval would receive several intervals for the same model partition that had to be scheduled. At least for changing and countdown clocks this is unnecessary because you are always looking from one clock tick to the next. For the periodic clocks this only means that the model partition can be scheduled with several intervals. If this use case is really necessary this could also be achieved by a scalar clock with interval attribute as list. Also attribute priority could have different values for one model partition then, which appears to be a strange use case. Here probably separate model partitions should be used.
However, if this interpretation is true, why must the clock array index be passed to fmi3ActivateModelPartition?

Shouldn't we forbid clock arrays in the standard? If anyone sees a use case for it, then it should be explicitly mentioned somewhere in the document what a clock array actually means and what it means when a variable is assigned to it.