OMEdit causes wrong simulation results

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

Please consider the attached simulation example IMCNominalOperation.NominalOperation. Run the example and compare the variables

• powerSensor.y.re
• imc.powerBalance.powerStator

These two variables must be equal and they are equal in Dymoa. In OpenModelica there exists a deviation by the factor of 3.

As all the voltages and currents are OK, the problem seems to be related with the evaluation of Modelica.Electrical.QuasiStationary.MultiPhase.Functions.activePower.

This issue refers to:

OMEdit 1.12.0~dev-156-g85fb2b9
Connected to OpenModelica 1.12.0~dev-328-g4f7ddab
Linux Mint 18.1 64bit

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

Esimulation example demonstrating the issue

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

Simulation result showing the deviation

[Adeel Asghar]

This might be a Linux issue as they appear same on Windows 64-bit.

[Willi Braun]

It works for me without the recently enabled modules wrapFunctionCall module.
A work-a-round is to disable it by +postOptModules-=wrapFunctionCalls.

@adeas31 Can you verify that this module was enabled and it still works on Windows.

[ahaumer@…]

I have the same problem on Windows64 with OpenModelica 1.11 beta 3.

[Lennart Ochel]

Replying to wbraun

Milestone changed from 1.12.0 to 1.11.0

Why did you change milestone to 1.11.0? The module wrapFunctionCalls will be introduced as feature with version 1.12.0.

[Willi Braun]

Replying to lochel:

Replying to wbraun

Milestone changed from 1.12.0 to 1.11.0

Why did you change milestone to 1.11.0? The module wrapFunctionCalls will be introduced as feature with version 1.12.0.

but it seems also be enabled by default for 1.11 beta 3 as

Replying to ahaumer@...
I have the same problem on Windows64 with OpenModelica 1.11 beta 3.

[Lennart Ochel]

I cannot reproduce the issue. Both signals seem to be equal. Maybe you could provide some more information on how to reproduce the issue.

[Lennart Ochel]

Replying to wbraun:

A work-a-round is to disable it by +postOptModules-=wrapFunctionCalls.

That does not work for me, because then the simulation execution fails.

Simulation execution failed for model: IMCNominalOperation.NominalOperation
DASKR--  AT T (=R1) AND STEPSIZE H (=R2) THE
      In above,  R1 =   9.3462593976256E-10   R2 =   7.7526609695740E-20
DASKR--  ERROR TEST FAILED REPEATEDLY OR WITH ABS(H)=HMIN
stdout            | warning | DDASSL had repeated error test failures on the last attempted step.
stdout            | warning | can't continue. time = 0.000000
stdout            | info    | model terminate | Integrator failed. | Simulation terminated at time 9.34626e-10

[Lennart Ochel]

Replying to wbraun:

but it seems also be enabled by default for 1.11 beta 3 as

No it's not.

[Willi Braun]

Okay, my first analysis was wrong it's not wrapFunctionCall. It's strange I can reproduce the issue with OMEdit, but not on command line with the same omc version.

[Martin Sjölund]

OMEdit sets -d=nogen while OMC does not. Does it impact the results?

[Lennart Ochel]

Replying to sjoelund.se:

OMEdit sets -d=nogen while OMC does not. Does it impact the results?

No. I just tried the example with -d=nogen and the two signals are still equal.

[Lennart Ochel]

As far as I can see, OMEdit sets the following flags to translate the model:

setMatchingAlgorithm("PFPlusExt"); getErrorString();
setIndexReductionMethod("dynamicStateSelection"); getErrorString();
setCommandLineOptions("-d=initialization"); getErrorString();
setCommandLineOptions("--simCodeTarget=C"); getErrorString();
setCommandLineOptions("--target=gcc"); getErrorString();
setCommandLineOptions("+profiling=none"); getErrorString();

However, it is not possible to reproduce the issue with this configuration. Adeel, what else does OMEdit?

[anonymous]

One of signals has a unit, where the other has not. related?

[Adeel Asghar]

Try calling the simulation executable from the command line with same arguments as OMEdit does.

[Lennart Ochel]

Replying to anonymous:

One of signals has a unit, where the other has not. related?

Signal imc.powerBalance.powerStator has unit W, whereas powerSensor.y.re has no unit. I cannot see how this could lead to difference of factor 3 between both signals.

[Adeel Asghar]

Its fixed in OMEdit 015e9da/OMEdit.
The problem is caused because some of the query API function is setting some flag and then not resetting it back. Willi is investigating more about it.

[Willi Braun]

With the following script we were able to reproduce the issue:

loadModel(Modelica, {"3.2.2"});
getErrorString();

loadFile("./IMCNominalOperation.mo");
getErrorString();

getComponentAnnotations(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.BaseClasses.PartialBasicMachine); getErrorString();

simulate(IMCNominalOperation.NominalOperation);

val(powerSensor.y.re, 0.001, "./IMCNominalOperation.NominalOperation_res.mat");
val(imc.powerBalance.powerStator, 0.001, "./IMCNominalOperation.NominalOperation_res.mat");

so the if
getComponentAnnotations(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.BaseClasses.PartialBasicMachine); is executed you get different results, otherwise the variables are equal.

[Adrian Pop]

Fixed in d9d4df/OMCompiler.
Added test in 5727bc/OpenModelica-testsuite.