What is the semantics of variability prefixes for function inputs

[qlambert-pro]

Modelica.Blocks.Tables.Internal.getTimeTableValueNoDer defines one of its inputs as discrete input Real nextTimeEvent; but I am not aware of an semantics associated with variability prefix. Is there? If not should the prefixes be removed from the MSL?

[HansOlsson]

Modelica.Blocks.Tables.Internal.getTimeTableValueNoDer defines one of its inputs as discrete input Real nextTimeEvent; but I am not aware of an semantics associated with variability prefix. Is there? If not should the prefixes be removed from the MSL?

It should be removed. It either has no impact or is illegal.

The variables in the function have discrete-time variability regardless of it ( https://specification.modelica.org/master/functions.html#function-as-a-specialized-class ), and the other use of "discrete" (to indicate that is is assigned in a when-clause) is clearly non-sensical in a function https://specification.modelica.org/master/class-predefined-types-and-declarations.html#S4.SS4.p3

[henrikt-ma]

Considering that the usage in https://github.com/modelica/ModelicaStandardLibrary/pull/4027 appears useful even though the semantics are currently not specified, we should consider more carefully to provide the missing semantics.

Suggested semantics: When a variability prefix is present on a function input component, corresponding arguments passed to the function must have compatible variability. The variability prefix has no semantics for the function body, where all expressions are discrete-time by definition.

[HansOlsson]

Considering that the usage in modelica/ModelicaStandardLibrary#4027 appears useful even though the semantics are currently not specified, we should consider more carefully to provide the missing semantics.

Suggested semantics: When a variability prefix is present on a function input component, this means that arguments passed to the function must have compatible variability. The variability prefix has no semantics for the function body, where all expressions are discrete-time by definition.

That seems like it has a major impact and would require an MCP, in particular since it is a new meaning for discrete separate from the usual one.

And since variables inside the function body had discrete variability it would imply that you could circumvent the variability check by a wrapper function - taking a normal Real and internally transforming it to a discrete Real expression and then use that to call another function.

A better solution is to look at the actual problem. There is no problem at all with calling the function, but when differentiating there is something odd that is handled by using noDerivative since we have no way of describing "zero derivative between events and ...".