Problem with initial equations affecting valve models in Modelica.Fluid

[Francesco Casella]

The PartialValve model in Modelica.Fluid had a wrong, redundant binding equation Av = 0, which resulted in getting Av = 0 with all choices of the CvData parameter except CvTypes.Av. This has now been fixed in r5718 of the MSL trunk, so the Av = 0 equation no longer shows up in the flattened model.

However, there is still some problem in the back-end. Please consider the attached test case, which is a Dymola Save Total containing the corrected Modelica model: nonwithstanding the initial equation

Av = Cv2Av*Cv

in the PartialValve model, valve.Cv = 1.4 but valve.Av = 0. As a result, all valve models that do not set the Av parameter directly always compute a wrong zero mass flow rate, regardless of the working conditions.

Can some of the back-end people have a look at that?

[Francesco Casella]

Save Total file

[Francesco Casella]

Script to run the test

[Lennart Ochel]

The problem is, that the fixed attribute of CvTypes.Av depends on further parameters.

[Lennart Ochel]

simple example with the same issue:

model test
  parameter Real a = 4;
  parameter Real b(start=0, fixed=(a < 3));
initial equation
  b = a + 3;
end test;

messages

"Warning: Trying to fix over-determined initial system... [not implemented yet!]
Warning: It was not possible to solve the over-determined initial system (3 equations and 2 variables)
Warning: No system for the symbolic initialization was generated. A method using numerical algorithms will be used instead.
"

[Lennart Ochel]

Currently we do just support constant variability for the fixed-attribute. I know that it is really common to use also parameter variability to describe the fixed-attribute. Maybe I have not seen it - but I guess it is not clearly described in the Spec, or is it?

[Jens Frenkel]

• We do also support Parameters with final=true and annotation(Evaluate=true).

From my point of view should a model with a not evaluateable (here I mean constants or parameter with final=true or annotation(Evaluate=true)) fixed binding commentet with at least a warning (much better is an error) by the compiler because if the binding changes the model may needs to be recompiled.

[Lennart Ochel]

Yes, you are right. We support those special cases as well. But the key-question is what is in the Spec? In the case that we do not have to support fixed-attributes with parameter variability, we should of course generate an error message. But maybe we have to support that as well?
If not, there are probably many bugs in the msl. That is why I am not really sure how to continue.

[Jens Frenkel]

• example from the Spec3.3 Page 91

parameter Boolean steadyState=true;
Real y (start=0, fixed=not steadyState);
Real der_y(start=0, fixed=steadyState) = der(y);

[Lennart Ochel]

I guess it is not that clear in the spec. Our approach is to provide also fixed-attributes with parameter variability (because of the example above and msl?!). But we will dump a warning, because these parameters should not be changed after compilation without recompilation. ... work in progress ...

[Francesco Casella]

Maybe I miss something, but there are lots of other cases where parameters cannot be changed without recompilation. These parameters are sometimes known in the community as "structural parameters" (because they affect the structure of the problem equations), though this concept is not defined in the Spec (should it?)

For example:

model M1 "Number of equations changes with the parameter"
  parameter Integer N = 1;
  Real x[N];
  ...
end M1;

model M2 "Index of DAE changes with the parameter"
  Real x1,x2,q;
  parameter Boolean equal = false;
equation
  der(x1) = 1-q;
  der(x2) = q;
  if equal then
    x1 = x2;
  else
    q = x1-x2;
  end if;
end M2;

model M3 "Optional thermal inertia"
  Modelica.SIunits.ThermalCapacity C;
equation
  if C>0 then
    C*der(T) = Q1+Q2;
  else
    0 = Q1 + Q2;
  end if;
end M3;

The latter case is a bit tricky - without the conditional equation, one would certainly get division by zero if C is set to zero after compilation. The if-equation makes it explict that the C=0 case is not an exception, but that it should be covered as well. In this case, evaluating C solves the problem. It is possible to be smarter than that, e.g. if the model is compiled with C > 0, then it should be possible to change C to other nonzero values after compilation (but not to set C = 0).

It would be weird if compiling this models would generate errors, or even warnings (I don't see anything wrong with them). Of course, a tool might be free to evaluate some of these parameters in order to avoid generating too complex simulation code. If you try to change the parameter afterwards, without recompiling, then (and only then!) you should get an error, because the compiled code does not allow to change it.

Anyway, as to what the Specification says, Sect. 4.1.8 defines the Real type with a "parameter" qualifier for all attributes. I assume this means that any expression with parameter variability can be used for the binding equations of attributes. The start attribute has been set by means of expressions having parameter variability for ages and nobody ever objected to this - I don't see why this shouldn't apply to the fixed attribute as well.

[Lennart Ochel]

I guess you are totally right. But anyway, this is not handled as you expect in OpenModelica. Maybe we should start a new ticket for the discussion of parameter handling during/after compilation.

However, this bug is fixed in r14461 by Jens.

[Jens Frenkel]

• a good work around could be to report not the warning but add an assert to the simulation runtime. The asserts checks the assumptions the compiler has done during compilation and is evaluated before simulations starts.