Check Variability of declaration equation (from MathCore)

[krsta]

From the spec: "For an assignment v:=expr or declaration equation v=expr, v must be declared to be at least as variable as expr."
This is not checked in the kernel.

For instance:

model A
  Real x;
  parameter Real y=x; // Should give error
  Real y(start=x); // Should give error
end A;

[Jan Brugård]

​http://intranet/trac/mathmodelica/ticket/1029

[Peter Aronsson]

Increased severity and priority since this is a fundamental part of Modelica. We (MathCore) have discovered that users tend to violate this rule quite often, and this leads to incorrect models, but NO WARNING or ERROR is given in OpenModelica. Therefore this is important to fix.

[AlexeyLebedev]

As I understand, it has already been implemented for algorithmic assignments, so I only had to work on bindings. I have implemented it (but not uploaded yet) with an exception and some side effects.

The exception is as following: it is still possible for a discrete component to have a binding of normal variability - for example,
{{{Real x;
discrete Real y = x;}}}

The reason is that the difference between discrete and normal variability exists in OMC only for components, but not for expressions, so it would require big changes to recognise such cases correctly.

The side effects are as following:

1. Expressions of the form size(array, int) and size(array) were assigned normal variability (DAE.C_VAR) if the corresponding array size has not been explicitly stated in the array's declaration. I have changed them to parametric variability. (Otherwise, examples like

Real x[:] (min = fill(1,size(x,1))) = {1.0};

would produce errors.) It seems a logical thing to do, though: the value of such expression cannot change in time. I would also suggest such change for built-in function ndims.

2. Test case ParameterDeclRecord

{{{record ParameterRecord
Real r;
end ParameterRecord;
class ParameterDeclRecord
parameter ParameterRecord pr;
equation
pr.r = 1.0;
end ParameterDeclRecord;}}}

now produces a warning
Parameter pc.r has no value, and is fixed during initialization (fixed=true)

Similar test case ParameterDeclConnector produces the same warning.

3. In test case Modelica3.x.Mechanics.MultiBody.Examples.Elementary.ForceAndTorque, parameters fixedRotation.R_rel_inv.T[i,j] and fixedRotation.R_rel_inv.w[i] now have bindngs in the output. A similar thing happens in test case Modelica3.x.Mechanics.MultiBody.Examples.Rotational3DEffects.GyroscopicEffects.

4. Test cases Philosopher and Philosopher2 now produce errors: they contain

{{{model Mutex "Mutual exclusion of shared resource"
constant Integer n=5 "The number of connected ports";
.......
end Mutex
parameter Integer n=5 "Number of philosophers and forks";
Mutex mutex(n=n);}}}

So, is this all OK? If yes, I will modify test cases so that they would not fail and upload all the changes.

[AlexeyLebedev]

It seems that previous absence of bindings of fixedRotation.R_rel_inv.T and w in test case Modelica3.x.Mechanics.MultiBody.Examples.Elementary.ForceAndTorque was caused by a bug in elaboration (caused by a bug in Lookup. lookupVarF) which I have fixed while implementing this (forgot to mention about it). When elaborating a qualified component a.b, compiler would assume that its variability is the variability of b in the class of a. I.e., in example
{{{class A
...
variability1 Real b;
end A;
variability2 A a;}}}

it would assume that variability of a.b is variability1. I have fixed it to use the more constant of variability1 and variability2 instead.

The case Modelica3.x.Mechanics.MultiBody.Examples.Elementary.ForceAndTorque contains the following:
{{{record Orientation
Real T[3, 3] "Transformation matrix from world frame to local frame";
SI.AngularVelocity w[3]
end Orientation;
 
model FixedRotation
final parameter Frames.Orientation R_rel=(some expression);
parameter Frames.Orientation R_rel_inv=Frames.from_T(transpose(R_rel.T), zeros(3));}}}

So, it seems, OMC would not do constant evaluation of Frames.from_T(transpose(R_rel.T), zeros(3)) because it assumed R_rel.T to be variable (as T is declared in Orientation), even though it is actually a parameter since being a subcomponent of parameter R_rel.

[AlexeyLebedev]

Uploadeed the changes in revision 5760

[Martin Sjölund]

{{{$ OPENMODELICAHOME=/opt omc a.mo
class A

Real x;
parameter Real y = x;

end A;
[a.mo:3:3-3:21:readonly] Error: Variable y: Component y of variability PARAM has binding x of higher variability VAR.}}}

It seems this is not fixed to 100%; the error message is generated, but instantiation still succeeds.

[AlexeyLebedev]

I have improved the fix, now this example fails.

[dhedberg]

This issue is not completely solved. I found that the following model still does not report any errors during checkModel().

model A
  Real x;
  parameter Real y=x; // Should give error
end A;

This has been confirmed by Adrian and hence I will reopen this issue.

[Adrian Pop]

I assign this to Per also because the problem with not displaying the message is in Inst.checkHigherVariability when checkModel option is on.

[Per Östlund]

Fixed in revision 6284, see test case mosfiles-nosim/ModifierVariabilityError.