Structural variability

[qlambert-pro]

Consider the following model, reduced from models in the Buildings library.

model VariableVariableVariability
  parameter Boolean b = false;
  Real y;
equation
  if b then
    when time > 3 then
      y = 2;
    end when;
  else
    y = time;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end VariableVariableVariability;

The variability to y depends on the value of b.
Is it valid?

[HansOlsson]

I would say it is legal, I don't see any restriction blocking that.
Obviously the parameter b must be evaluated, and we might make the rules clearer, in particular it currently only states that the branches need to have the same number of equations if not evaluable parameer - but that restriction should be clearer to rule out this case as well.

[HansOlsson]

The number of equations is from: https://specification.modelica.org/master/equations.html#if-equations
But b must be evaluable: https://specification.modelica.org/master/equations.html#restrictions-on-where-a-when-equation-may-occur, so it may be a matter of just stating that additional conditions may apply.

Note that number of equations is misleading in these cases:

• Different types; one cannot replace a boolean equation with a real equation.
• Discrete real vs continuous-time real (the case above)
• Clocked vs. non-clocked (or at least unclear)

Note that the discrete part is somewhat complicated, as

model Test
  parameter Boolean b = true annotation(Evaluate=true);
  Real y, yd;
equation
  when time > 3 then
    yd = 2;
  end when;
  if b then
    y = yd;
  else
    y = time;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end Test;

works perfectly, and one can even write: y=if b then yd else time; or y=a1*yd+a2*time; Or basically y isn't derived to be discrete-time-variable even when it is bound to a variable that is discrete-time-variable.

[henrikt-ma]

The point of the example is not the equation counting, but that y can be said to be assigned in a when-clause unless the if-equation is forced to be reduced to one of its branches before determining whether y is a discrete-time component. Thus, to make it legal, one would need the rule for discrete-time components to only look for variables assigned in when-clauses after certain simplifications given by the specification have been applied.

[HansOlsson]

The point of the example is not the equation counting, but that y can be said to be assigned in a when-clause unless the if-equation is forced to be reduced to one of its branches before determining whether y is a discrete-time component. Thus, to make it legal, one would need the rule for discrete-time components to only look for variables assigned in when-clauses after certain simplifications given by the specification have been applied.

Well, we currently require that the condition of an if-clause controlling a when-clause is evaluable (we currently say "parameter expression" but I assume that is a rest from before evaluable was introduced), so those simplifications should be possible to do at least. (There's also a restriction on the conditions of some if-clauses inside when-clauses.)

Note that there is even an example of this in the specification:

  parameter Boolean b = true ;
  parameter Integer n = 3;
  Real x [ n ];
equation
  if b then
    for i in 1 : n loop
       when sample (i , i ) then
          x [ i ] = time ;
       end when ;
    end for;
  end if;

I missed it at first, since the when-clause is not only inside an if-clause, but also inside a for-clause.

Since the variability of y determines whether pre(y) is legal outside of when-clauses we have the following possibilities:

• Evaluate the conditions of those if-clauses (and for-clauses) before determining variability, which makes sense to me. A bit of clarification.
• Treat pre(y) as legal as long as there exists a when-clause for it, even if the when-clause is disabled (very bad)
• Treat pre(y) as illegal unless the when-clause is unconditional - which would require additional explanation.

[henrikt-ma]

Sure, there is a connection to pre(y), but let's make sure to formulate the clarification in terms of the variability of y, not whether pre(y) is valid outside when-clauses.

[qlambert-pro]

Is this model valid then:

model VariableVariableVariability5
  parameter Boolean b = true;
  discrete Real y;
equation
  if b then
    when time > 3 then
      y = 2;
    end when;
  else
    y = time;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end VariableVariableVariability5;

[HansOlsson]

Is this model valid then:

model VariableVariableVariability5
  parameter Boolean b = true;
  discrete Real y;
equation
  if b then
    when time > 3 then
      y = 2;
    end when;
  else
    y = time;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end VariableVariableVariability5;

With the current proposed wording the model would be valid, but changing the parameter b would make it invalid.

I agree that ideally it should be invalid, but:

• I don't know exactly how.
• I don't see a realistic scenario with such models.

The most realistic variant I could think of would be something like:

package P
  partial model Base
    parameter Boolean b=false;
    Real y;
  equation 
    if b then
      when time > 3 then
        y = 2;
      end when;
    else
      y = time;
    end if;
  end Base;

  model M
    extends Base(b=true, redeclare discrete Real y);
    annotation (experiment(StopTime=1.0));
  end M;
end P;

[qlambert-pro]

I don't see a realistic scenario with such models.

What if a library developer added the discrete keyword assuming that the tool would be able to detect cases where y is not assigned in a when construct?

[qlambert-pro]

There is also this related model:

model DependentDiscreteTest
  parameter Boolean b = true;
  Real y;

  function f
    input Real i;
    output Boolean o = i > 1;
  algorithm
  end f;

  Boolean b2 = f(y);
equation
  if b then
    when time > 3 then
      y = 2;
    end when;
  else
    y = time;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end DependentDiscreteTest;

Is it not possible to include a line saying that it is up to the tool implementation to detect variability related issues that would arise for different value of the evaluated conditions?

[HansOlsson]

I don't see a realistic scenario with such models.

What if a library developer added the discrete keyword assuming that the tool would be able to detect cases where y is not assigned in a when construct?

Just to be clear: if b is false it is invalid, so that case is detected.

Given that why then have the when-clause inside an if-clause? Except for redeclare the when-clause and discrete declaration must be close together, so it is a matter of a local check, not a matter of checking different sub-systems (as the when-clause cannot be inside a sub-component).

I'm not saying that such models cannot occur, just that I find them odd. Thus I don't see a major problem with treating them as valid (when b is true, obviously b=false will make it invalid), unless we can find a good solution.

However, I also see it similar to:

model Test
  parameter Boolean b = true;
  Real y;
equation
  if b then
     y = 2;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end Test;

which is only balanced if b is true; and it is specified that it is a quality-of-implementation issue to report that it isn't balanced otherwise. It may be that one could formulate something similar for this.

One could also make this similarity clearer:

model TestCase
  parameter Integer case(final max=3) = 1;
  input Boolean u;
  discrete Real y;
equation
  if case==1 then
     when time>=1 then
       y=1;
    end when;
  end if;
  if case==2 then
     when sample(1,1) then
       y=2;
    end when;
  elseif case==3 then
     when u then
       y=3;
    end when;
  end if;
  annotation(
    experiment(
      StopTime = 1.0
    )
  );
end TestCase;

Setting case=0 makes it unbalanced, and also means that y no longer is given in a when-clause.

[HansOlsson]

Is it not possible to include a line saying that it is up to the tool implementation to detect variability related issues that would arise for different value of the evaluated conditions?

Yes, that would be possible.

[HansOlsson]

Is it not possible to include a line saying that it is up to the tool implementation to detect variability related issues that would arise for different value of the evaluated conditions?

Yes, that would be possible.

I have now tried to add it. I don't fully like the quality of implementation formulation, but I copied it from balanced models (and made it non-normative to match) - so if we are to improve it we should to it consistently.