Parameter binding equations for Complex parameters are incorrectly moved to the equation section by the NF

[Francesco Casella]

Please consider the attached test package case. If the Circuit1 model is flattened, the result is:

class TestComplexConnect.Circuit1
  parameter Real V1.v.re(quantity = "ElectricPotential", unit = "V") "Real part of complex number";
  parameter Real V1.v.im(quantity = "ElectricPotential", unit = "V") "Imaginary part of complex number";
  Real V1.p.v.re(quantity = "ElectricPotential", unit = "V") "Real part of complex number";
  Real V1.p.v.im(quantity = "ElectricPotential", unit = "V") "Imaginary part of complex number";
  Real V1.p.i.re(quantity = "ElectricCurrent", unit = "A") "Real part of complex number";
  Real V1.p.i.im(quantity = "ElectricCurrent", unit = "A") "Imaginary part of complex number";
  Real Z1.p.v.re(quantity = "ElectricPotential", unit = "V") "Real part of complex number";
  Real Z1.p.v.im(quantity = "ElectricPotential", unit = "V") "Imaginary part of complex number";
  Real Z1.p.i.re(quantity = "ElectricCurrent", unit = "A") "Real part of complex number";
  Real Z1.p.i.im(quantity = "ElectricCurrent", unit = "A") "Imaginary part of complex number";
  parameter Real Z1.Z.re(quantity = "Resistance", unit = "Ohm") "Real part of complex number";
  parameter Real Z1.Z.im(quantity = "Resistance", unit = "Ohm") "Imaginary part of complex number";
equation
  V1.p.v.re = Z1.p.v.re;
  V1.p.v.im = Z1.p.v.im;
  Z1.p.i.re + V1.p.i.re = 0.0;
  Z1.p.i.im + V1.p.i.im = 0.0;
  V1.v = Complex.'constructor'.fromReal(1.0, 0.0);
  V1.p.v = V1.v;
  Z1.Z = Complex.'constructor'.fromReal(0.0, 1.0);
  Z1.p.v = Modelica.SIunits.ComplexImpedance.'*'.multiply(Z1.Z, Z1.p.i);
end TestComplexConnect.Circuit1;

For some reason the binding equations for the Complex parameters V1.v and Z1.Z were moved from the parameter binding equations to the equation section, which makes the model overdetermined and at the same time leaves the parameters without any binding equation, which is mandatory for parameters having fixed = true.

[Per Östlund]

The reason an equation is generated is because the Complex constructors can't be evaluated, due to the missing evaluation of userdefined functions. And since Record constructors should always be possible to evaluate (should they? The old frontend assumes so at least) the DAE structure has no way to represent using a record field of a generic expression. So until we can evaluate these constructors we stick them in an equation, because that's slightly better than just ignoring them.

[Francesco Casella]

I'm not sure how difficult it is to have these constructors evaluated - I guess something very basic should be fine, since I never saw anything fancy in there: literal constants, individual parameters, individual variables, and very simple arithmetic expressions involving them.

If this a non-trivial task, then an interim solution when you have parameter binding equations with Complex constructors would be to set fixed=false in the parameter definitions and put the equation with the constructor in the initial equation section. Is that easily accomplished?

[Per Östlund]

Replying to casella:

If this a non-trivial task, then an interim solution when you have parameter binding equations with Complex constructors would be to set fixed=false in the parameter definitions and put the equation with the constructor in the initial equation section. Is that easily accomplished?

It would be fairly easy, but evaluating the constructors isn't particularly complicated either. I'm planning on massively improving the constant evaluation once I'm done with the binding issues, so this should be fixed properly sooner rather than later.

[Per Östlund]

The original issue was fixed a while ago, and with the fixes in d1ab9a0 and 09f9ddd it now simulates. The DistributionSystemLinear* models in the ScalableTestSuite also simulate now, which I assume was the real point of this ticket.

[Francesco Casella]

Replying to perost:

The DistributionSystemLinear* models in the ScalableTestSuite also simulate now, which I assume was the real point of this ticket.

Indeed. In fact, I have several other very interesting confidential test cases that I should now be able to run. I'll do that later this week.