OMEdit: Default value overwrite has no effect / is allowed

[Jan Kokert]

Let's consider creating a model with components having default values (e.g. a constant voltage, a resistor and a gnd with no parameters set). After simulation, the user can change the parameters in OMEdit VariablesBrowser like constantvoltage1.V = 2 and hit Re-simulate.
-> But the simulation results will still be based the original values!

I'm not quite sure, what the actual error is, so if
a.) editing default values in VariablesBrowser is allowed by accident or if
b.) new values in OMEdit are not correctly transferred to the overwriting process or if
c.) overwriting the default values goes wrong

The ticket is related to:
#2981 Unfixed parameters should not be changeable for resimulation and
#2759 Override value not correctly displayed in OMEdit Variables Browser

I hope this can be fixed, because for new user it is a confusing behaviour.

[Adeel Asghar]

Seems like an issue with simulation executable not properly reading the model_init.xml file.

I have created a script which first simulates the model with default values and plots constantvoltage1.V the result is 1. Then it changes the value to 2 and updates the init xml file. Re runs the simulation and plots constantvoltage1.V. The result is still 1.

[Jan Kokert]

updated model file

[Jan Kokert]

Creating a script is a good idea. But the small model (M.mo) was intended to be little bit different. At least on connection is missing. I've uploaded a new one.

[Willi Braun]

As far as I see it's an initialization issue. The following one equation model has the same issue:

model Test
  Real x = a, y;
  parameter Real a(start=1);
equation
  y = x * time;
end Test;

We set a = 1 while initialization and don't consider the start value anymore.

[Jan Kokert]

Ok, good example! Then it seems to be a serious bug. During simulation in OMEdit we receive a warning, that some parameters have no value and that they are fixed during initialization.

So for me it is still not clear, what the desired behavior is, so if a), b) or c) is true.
As a user I'd like to overwrite/re-simulate also default values, so fixing a) might not be the solution...

[Lennart Ochel]

I guess this issue is solved with r23613. Nevertheless, the handling of parameters could be improved, since such without a binding but a start value could be solved before solving the actual variables.
I added the test from above to the test suite.

[Willi Braun]

It seems that r23613 break some msl31 examples with initialization issues:
​https://test.openmodelica.org/hudson/view/Library%20Testing/job/MSL_3.1_Simulation/454/testReport/

I think the following models shows the issue:

loadString("
model A
  parameter Real a(start=1);
  parameter Real b(start=2*a);
end A;
");
getErrorString();
simulate(A);
getErrorString();
val(a,0.0);
val(b,0.0);

[Lennart Ochel]

Replying to wbraun:

It seems that r23613 break some msl31 examples with initialization issues:
​https://test.openmodelica.org/hudson/view/Library%20Testing/job/MSL_3.1_Simulation/454/testReport/

I think the following models shows the issue:

loadString("
model A
  parameter Real a(start=1);
  parameter Real b(start=2*a);
end A;
");
getErrorString();
simulate(A);
getErrorString();
val(a,0.0);
val(b,0.0);

We know about it.

[Lennart Ochel]

I reverted my latest changes, since it breaks initialization of parameters in some cases as discussed with Adrian this morning. I will create a better patch for this ticket.

[Lennart Ochel]

I fixed it in r23848.