Various places where parameter variability seems too high

[henrikt-ma]

This issue collects a number of items questioning the use of parameter variability, when evaluable variability seems to make more sense. (The issue was originally formulated just for smooth, but was generalized in order to not result in too many, too similar, issues.)

I haven't analyzed all of these carefully, but I find it better to err on the side of bringing up too many on the table than bringing up too few, and leave it for the group to determine which cases we shouldn't touch.

smooth

I believe that the purpose of the smooth operator, https://specification.modelica.org/master/operators-and-expressions.html#modelica:smooth, is to allow tools to use the smoothness information during symbolic processing. Hence, I believe it is a mistake that it is currently not required that the smoothness order is evaluable.

Strictly speaking, also a non-evaluable smoothness order could have been used for integration method order selection, but this appears far more complicated to implement than what I believe is the intention behind the design.

cat

The dimension $k$ along which cat should operate, https://specification.modelica.org/master/arrays.html#array-concatenation.

Component condition

The introduction to the section needs to use correct variability when talking about the component condition, or not talk about its variability at all: https://specification.modelica.org/master/class-predefined-types-and-declarations.html#component-declarations

Just saying this might be good enough:

an optional Boolean condition

Array dimensions example

From the array dimensions example in https://specification.modelica.org/master/class-predefined-types-and-declarations.html#component-declaration-static-semantics:

  parameter Integer n = 0;
  Real z[n*2] = cat(1, ones(n), zeros(n));// Parameter expressions are allowed

Connections.root

Since connection handling happens during translation, non-evaluable variability in the non-normative remark seems wrong: https://specification.modelica.org/master/connectors-and-connections.html#modelica:Connections.root

Also note the incorrect grammar in a parameter expressions.

Equations within when-equations

Maybe we already have an open issue about this, but in case we don't: https://specification.modelica.org/master/equations.html#equations-within-when-equations

This sounds wrong:

unless all switching conditions of the if-equation are parameter expressions

Array dimensions in functions as specialized class

From https://specification.modelica.org/master/functions.html#function-as-a-specialized-class:

or given by constant or parameter expressions

Subscripts inside pre

Restriction on the subscripts inside pre(…): https://specification.modelica.org/master/operators-and-expressions.html#modelica:pre

Restrictions for transitions

The if-equation restriction for state machine transition operators: https://specification.modelica.org/master/state-machines.html#transitions

This looks wrong:

cannot be used inside if-equations with conditions that are not parameter expressions

Synchronous argument restrictions

https://specification.modelica.org/master/synchronous-language-elements.html#argument-restrictions-component-expression

Looks like this was forgotten:

In cases when special handling of parameter expressions is specified, it is an indication that the values are not needed during translation.

Real interval clock

https://specification.modelica.org/master/synchronous-language-elements.html#modelica:clock-interval

Two occurrences of parameter expression, but I believe the intention is to allow computations on the periodic clock interval during translation?

hold

https://specification.modelica.org/master/synchronous-language-elements.html#modelica:hold

Input argument $u$ is a … or a parameter expression.

It would just be a bit unusual to see the use of parameter expression in this chapter, but I must say that applying hold to a non-evaluable parameter expression seems pretty harmless.

[HansOlsson]

I agree with most of them, but not for synchronous chapter.

Synchronous argument restrictions

https://specification.modelica.org/master/synchronous-language-elements.html#argument-restrictions-component-expression

Looks like this was forgotten:

In cases when special handling of parameter expressions is specified, it is an indication that the values are not needed during translation.

As I see it that text is correct currently, but it may need some extra explanation. As an example of the intention see the final case below.

I don't know if it should be clarified further, and mentioning evaluable might cause more confusion.

Real interval clock

https://specification.modelica.org/master/synchronous-language-elements.html#modelica:clock-interval

Two occurrences of parameter expression, but I believe the intention is to allow computations on the periodic clock interval during translation?

Not for real interval clocks.

We may need to evaluate rational interval clocks, in order to see if they are synchronous or not; that's why they should be evaluable. However, real interval clocks will never be synchronous so that doesn't apply.

Let's consider three examples to demonstrate the difference:

model SeparateClocks
  parameter Integer p=1;
  parameter Real p2=1;
  Real x, y;
equation 
  when Clock(p) then
    x=previous(x)+1;
  end when;
  when Clock(p2) then
    y=previous(y)+1;
  end when;
end SeparateClocks;

Those two clocks are completely separate and tools may skip evaluating the evaluable p and the parameter p2.

model TwoRationalMixed
  parameter Integer p=1;
  parameter Integer p2=1;
  Real x, y;
equation 
  when Clock(p) then
    x=previous(x)+1;
  end when;
  when Clock(p2) then
    y=previous(x)+1; // Note: using x
  end when;
end TwoRationalMixed;

Those two clocks are mixed (so it is only one clock partition), which requires that p and p2 are the same, so they must both be evaluated; see https://specification.modelica.org/master/synchronous-language-elements.html#sub-clock-inferencing

model TwoRealMixed
  parameter Real p=1;
  parameter Real p2=1;
  Real x, y;
equation 
  when Clock(p) then
    x=previous(x)+1;
  end when;
  when Clock(p2) then
    y=previous(x)+1; // Note: using x
  end when;
end TwoRealMixed;

That is attempting to mix two real clocks (in one clock partition), which is not legal, so it doesn't make sense to require that they are evaluable, as evaluating them wouldn't help.

BTW: We should have a linkable sub-section to the end of https://specification.modelica.org/master/synchronous-language-elements.html#clock-constructors where the various cases are listed.

hold

https://specification.modelica.org/master/synchronous-language-elements.html#modelica:hold

Input argument
u
is a … or a parameter expression.

It would just be a bit unusual to see the use of parameter expression in this chapter, but I must say that applying hold to a non-evaluable parameter expression seems pretty harmless.

Yes, and that goes back to the "Synchronous argument restrictions", as that is one of the intended cases.

[henrikt-ma]

We may need to evaluate rational interval clocks, in order to see if they are synchronous or not; that's why they should be evaluable. However, real interval clocks will never be synchronous so that doesn't apply.

Isn't the potential need for evaluation sufficient to make evaluable variability generally required? In SeparateClocks, there is nothing forcing the tool to evaluate p, but restriction to evaluable variability would make some very funky setups illegal, like this:

  parameter Integer p(fixed = false);
  Real x(start = 3, fixed = false);
initial equation
  x^2 = 10;
  p = integer(x);
equation 
  when Clock(p) then
    …
  end when;

[HansOlsson]

We may need to evaluate rational interval clocks, in order to see if they are synchronous or not; that's why they should be evaluable. However, real interval clocks will never be synchronous so that doesn't apply.

Isn't the potential need for evaluation sufficient to make evaluable variability generally required?

Yes, and that's why the rational interval clocks use evaluable https://specification.modelica.org/master/synchronous-language-elements.html#modelica:clock-rational - but real interval clocks don't.

However, the problem here is that rational interval clocks are allowed to be either evaluable (periodic) or clocked expression (non-periodic). And treating a parameter as a clocked expression would seem harmless. Explaining this may require more thought, but I don't see a reason to change that section.

[HansOlsson]

We should discuss this, but to me there are two clear actions:

• Update the non-synchronous sections based on this.
• Don't update the synchronous section based on this, but instead make it possible to link to the end of https://specification.modelica.org/master/synchronous-language-elements.html#clock-constructors where restrictions are listed.

[HansOlsson]

Language group: No objections. @henrikt-ma make PR non-synchronous part.