Complex division is not working in MSL simulation example

[Christian Kral <dr.christian.kral@…>]

I recently implemented a Bode block in the MSL, see ​https://github.com/modelica/Modelica/issues/2473. Today I improved the Bode model in the MSL order to overcome some numerical and initialization problems.

Now, please consider example Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode (on master):

• The simulation example simulates with no obvious complaints
• The complex inputs bode.u and bode.divisor look reasonable
• The division of the two complex inputs, however, is incorrect (see attached file), i.e., divison.y.re = division.y.im = 0 ... the results shall NOT be zero

I do not understand where this comes from, as the simple test example

model TestComplexDivision
  Modelica.ComplexBlocks.Sources.ComplexConstant complexConst1(k = Complex(1, 1))  annotation(
    Placement(visible = true, transformation(origin = {-70, 10}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  Modelica.ComplexBlocks.Sources.ComplexConstant complexConst(k = Complex(2, 3))  annotation(
    Placement(visible = true, transformation(origin = {-70, -30}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  Modelica.ComplexBlocks.ComplexMath.Division division1 annotation(
    Placement(visible = true, transformation(origin = {-30, -10}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation
  connect(complexConst.y, division1.u2) annotation(
    Line(points = {{-58, -30}, {-50, -30}, {-50, -16}, {-42, -16}, {-42, -16}}, color = {85, 170, 255}));
  connect(complexConst1.y, division1.u1) annotation(
    Line(points = {{-58, 10}, {-50, 10}, {-50, -4}, {-42, -4}, {-42, -4}}, color = {85, 170, 255}));

end TestComplexDivision;

works OK and the division1.y shows the correct result.

So TestComplexDivision works OK, but Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode does not work.

This issue applies to

OMEdit 1.13.0~dev-106-g36aa34a
Connected to OpenModelica 1.13.0~dev-729-gdbcd957

on a 64bit Linux machine.

[Christian Kral <dr.christian.kral@…>]

Result plot of Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode

[Martin Sjölund]

The variable seems to be wrongly assumed to be time-independent and the equation is probably calculated without even using the correct time=0 values of the input for this reason... The first place where this occurs seems to be at "pre-optimization module removeSimpleEquations (simulation)". --removeSimpleEquations=none makes the model simulate fine.

[Francesco Casella]

After the last commits to the NF, with v1.13.0-dev-1096-g6770e6300 this test model now works and produces the correct result, namely 0.3846 - j0.0769.

[Christian Kral <dr.christian.kral@…>]

I just checked again on Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode and it turns out that this example is not simulating correctly.

OMEdit 1.14.0~dev-48-g43ebf04
Connected to OpenModelica 1.14.0~dev-353-g7912862
Connected to OMSimulator unknown-linux

I do not know if this is still relevant for the "old compiler" or if I have to use the option --removeSimpleEquations=none (which I could not get to work; I do not know where to put in the simulation setup dialog): However, I just wanted to report it. You may respond, that this is not relevant any more...

[Christian Kral <dr.christian.kral@…>]

Simulation result

[Christian Kral <dr.christian.kral@…>]

To be more precise: "not simulating correctly" means the shown "Simulation result" shall NOT be zero.

[Christian Kral <dr.christian.kral@…>]

The issue also appears using -d=newInst.

[Christian Kral <dr.christian.kral@…>]

Tested with MSL 3.2.3

[Per Östlund]

I can't reproduce this, simulating the SeriesBode model from MSL 3.2.3 with both the old and the new instantiation gives the same results, see the attached image.

[Martin Sjölund]

We do test against the reference results of ​MA, but these seem to only compare one variable (inductor.pin_p.reference.gamma)...

[Christian Kral <dr.christian.kral@…>]

This is strange: I attached a screenshot of my results including the info on the MSL and version number of OMEdit. Could that be a Linux issue?

However, comparing just inductor.pin_p.reference.gamma may not be sufficient. Could it actually be possible that I have no access to the ​MA link you provided? Even ​https://github.com/modelica/MAP-LIB_ReferenceResults seems not to be accessible to me. In both cases I get a 404 error message (this is not the web page you are looking for)

[Christian Kral <dr.christian.kral@…>]

OM version

[Christian Kral <dr.christian.kral@…>]

SeriesBode simulation result including MSL version number

[Per Östlund]

Replying to Christian Kral <dr.christian.kral@…>:

Could that be a Linux issue?

Probably not, I also used 64-bit Linux when simulating the model. I used a slightly newer version of OMC than you have (git master at this moment), and there seems to have been a few library updates since your version. So I guess it's possible that this was actually broken before but somehow got fixed in the last few days. Can you update to the latest nightly build and try again?

[Martin Sjölund]

Replying to Christian Kral <dr.christian.kral@…>:

Could it actually be possible that I have no access to the link you provided? Even ​https://github.com/modelica/MAP-LIB_ReferenceResults seems not to be accessible to me. In both cases I get a 404 error message (this is not the web page you are looking for)

Most probably. I have added the MAP-LIB group to have read access to that for now (it's a new repo so it's missing some rights).

[Christian Kral <dr.christian.kral@…>]

I installed

OMEdit 1.14.0~dev-48-g43ebf04
Connected to OpenModelica 1.14.0~dev-355-gd61da53
Connected to OMSimulator unknown-linux

and I see no difference. The output of two variables abs_y and arg_y is always identical to zero.

[Christian Kral <dr.christian.kral@…>]

I actually noticed that this thicket was closed three months ago, referring to v1.13.0-dev-1096-g6770e6300. I just now tested the model with

OMEdit v1.13.1 (64-bit)
Connected to v1.13.1 (64-bit)
Connected to OMSimulator v2.0.0-mingw

on a Windows system remotely, which shows also zero results for abs_y and arg_y.

[Christian Kral <dr.christian.kral@…>]

SeriesBode on Windows 7 with OMEdit 1.13.1

[Christian Kral <dr.christian.kral@…>]

When re-reading my response I realized that the version number did not change after updating from the repository

I installed

OMEdit 1.14.0~dev-48-g43ebf04
Connected to OpenModelica 1.14.0~dev-355-gd61da53
Connected to OMSimulator unknown-linux

and I see no difference. The output of two variables abs_y and arg_y is always identical to zero.

This seems to be the most recent version on the repository.

[Francesco Casella]

I double-checked with yesterday's nightly on Windows

OMEdit v1.14.0-dev-48-g43ebf040 (64-bit)
Connected to v1.14.0-dev-154-g04f106144 (64-bit)
Connected to OMSimulator v2.1.0-dev-64-gafc407f-mingw

The issue is located in the bode.division complex division block: the two inputs u1 and u2 are computed correctly, but the output y is incorrectly computed to zero. This happens independently of the used frontend.

I tried to figure out what goes wrong by looking at the -d=optdaedump output. As already mentioned in comment:2, for some reason the back-end considers the output of that block as a constant expression, so it moves the computation to the initial known variables section, and somehow evaluates it to zero during initialization.

Known variables only depending on parameters and constants - globalKnownVars (49) 
======================================== 
<snip>
32: bode.y.im:VARIABLE(flow=false fixed = false )  = ((if bode.division.useConjugateInput1 then Complex(bode.division.u1.re, -bode.division.u1.im) else bode.division.u1).im * (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).re - (if bode.division.useConjugateInput1 then Complex(bode.division.u1.re, -bode.division.u1.im) else bode.division.u1).re * (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).im) / ((if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).re ^ 2.0 + (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).im ^ 2.0)  "Imaginary part of complex number" type: Real  
33: bode.y.re:VARIABLE(flow=false fixed = false )  = ((if bode.division.useConjugateInput1 then Complex(bode.division.u1.re, -bode.division.u1.im) else bode.division.u1).re * (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).re + (if bode.division.useConjugateInput1 then Complex(bode.division.u1.re, -bode.division.u1.im) else bode.division.u1).im * (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).im) / ((if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).re ^ 2.0 + (if bode.division.useConjugateInput2 then Complex(bode.division.u2.re, -bode.division.u2.im) else bode.division.u2).im ^ 2.0)  "Real part of complex number" type: Real  

The right-hand sides of these two equations seem correct to me, but for some reason they are considered to be known variables. This is of course wrong because bode.division.u1 and bode.division.u2 show up in their expression, and they are most definitely not known variables. I'm not sure where the generated code picks up the constant values of bode.division.u1 and bode.division.u2 during initialization.

As noticed in comment:2, setting --removeSimpleEquations=none solves the problem, so I guess there's still something wrong there. I would suggest to investigate this with high priority, because it's really a bad bug: simulation works, but results are wrong.

We also need to improve the MSL reference result files for these state-less systems, otherwise we risk not catching other similar errors, but this is a MAP-LIB issue.

[Christian Kral <dr.christian.kral@…>]

We also need to improve the MSL reference result files for these state-less systems, otherwise we risk not catching other similar errors, but this is a MAP-LIB issue.

I very much agree that we should avoid to not sense issues due to non-existing states. I had a look at the Model Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode and there the following output variables are defined:

  output Real abs_y = bode.abs_y "Magnitude of voltage ratio";
  output Modelica.SIunits.AmplitudeLevelDifference dB_y = bode.dB_y 
    "Log10 of magnitude of voltage ratio in dB";
  output Modelica.SIunits.Angle arg_y = bode.arg_y "Angle of voltage ratio";

From my understanding there should exist reference results for all variables identified as output quantities, isn't it? From my understanding Leo Gall is managing the reference results of the MSL. Is that correct?

[Martin Sjölund]

Yes, Leo handles the reference results. But I'm sure he would accept a pull request to ​https://github.com/modelica/MAP-LIB_ReferenceResults or other feedback (the ticket system seems disabled for it though).

[Francesco Casella]

I would suggest you to contact Leo directly and sort this out with him.

[Karim Adbdelhak]

The main issue regarding Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode should be fixed in ​commit. Can we close this ticket or are there new issues?

[Francesco Casella]

I just ran the Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesBode example again with the latest Windows nightly v1.14.0-dev-165-gf63f7ac40, and it seems to me that the output of the bode block is now correct.

@Christian, please double-check and reopen the ticket if you still find issues.

Thanks @Karim for the quick fix!

[Martin Sjölund]

@Karim: I wouldn't call that a fix if it is hard-coded for Complex.mo and breaks for any other package (or possibly aliases of Complex). We have very little hard-coded code referencing the MSL (mostly things for ModelicaExternalC).

[Karim Adbdelhak]

Replying to sjoelund.se:

@Karim: I wouldn't call that a fix if it is hard-coded for Complex.mo and breaks for any other package (or possibly aliases of Complex). We have very little hard-coded code referencing the MSL (mostly things for ModelicaExternalC).

Yes that is true, but i did not see another way to detect if something is complex to avoid this special kind of alias. I guess the best way to handle this is, once again, consider stuff like this as array equations and handle them properly. Since i will be working on that in the future i will (hopefully) propose a better solution, but for know i thought this would do.

Do you have other ideas how to handle this?

[Martin Sjölund]

Look if the type is a record instead, perhaps?

[Christian Kral <dr.christian.kral@…>]

I created new reference results for SeriesBode and sent them to Leo Gall. Unfortunately I cannot create a pull request, as the ​https://github.com/modelica/MAP-LIB_ReferenceResults is a private repository which cannot be forked...

I expect Leo Gall to update the new reference data anytime soon.

[Francesco Casella]

@Karim, can you implement @sjoelund's suggestion in comment:23 so we can close this ticket in 1.14.0?

Thanks!

[Karim Adbdelhak]

I changed it in ​commit. It avoids records now, should work with all libraries.

[Francesco Casella]

This also fixed a numerical initialization failure with Modelica.Fluid.Examples.Explanatory.MomentumBalanceFittings, which nows passes verification successfully.

[dr.christian.kral@…]

Replying to Christian Kral <dr.christian.kral@…>:

I created new reference results for SeriesBode and sent them to Leo Gall. Unfortunately I cannot create a pull request, as the ​https://github.com/modelica/MAP-LIB_ReferenceResults is a private repository which cannot be forked...

I expect Leo Gall to update the new reference data anytime soon.

The new reference results are now available.