Initial conditions are not considered properly when applying Re-simulate

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

Consider the following example

model ReSimulate
  Real x;
initial equation
  x=0;
equation
  der(x)=1;
end ReSimulate;

After the simulation of this example, an input field for the initial condition of the variable x appears in the Plotting tab. When I enter 1 and re-simulate, the result does not change. So obviously, the changed initial condition is not taken into account.

If instead the model

model ReSimulate
  Real x(start=0);
equation
  der(x)=1;
end ReSimulate;

is used, the change of the initial condition works just fine.

[Lennart Ochel]

I guess the input field only overrides the start values and doesn’t replace the actual initial conditions. You can disable the initial equations using -iim=none and re-simulate by applying proper start values.

[Martin Sjölund]

I guess the bug here is that x is marked as changeable. Is this because in the regular system of equations, x is a state variable and der(x) has an equation that we just assume x.start influences the system?

[anonymous]

Maybe it is ok if we consider changeable the initial values of all state variables.
In this case the value set by omedit should be considered after (not before) initial equations are evaluated.

[Martin Sjölund]

I don't think that's a good idea. Equations should hold. Perhaps the only reason to consider something like that is because having start=x, fixed=false should be equivalent to an initial equation (or is it? I didn't check the spec).

[anonymous]

Replying to sjoelund.se:

[...] Perhaps the only reason to consider something like that is because having start=x, fixed=false should be equivalent to an initial equation (or is it? I didn't check the spec).

This what I was thinking of, on one hand. I've always thought initial equations as tool to set initial conditions (just like "start=x"), and much ore (for instance when we use a true equation, not just variable=something known).
On the other hand, I think that what we make OMEdit do when we re-run, is not a matter of specs. Is more a matter of usability.
If the programming effort to do what I suggested is not too big, I think it should be considered. We will give OMEdit users an additional opportunity, without losing anything.
What do you think, @Kral?

[Martin Sjölund]

The problem is if you have some equation like:

model ReSimulate
  Real x, y=sin(x);
initial equation
  x=cos(x);
equation
  der(x)=1;
end ReSimulate;

Can you still set x=7.0? Would y use this value 7.0 to be solved, or the solved value of the algebraic loop x=cos(x)? And would the user's value override this? Each of these answers influences how the system is solved.

[anonymous]

My idea is that we should make it clear that
values manually set in Variables Browser are used in simulations, no matter what results from "start" modifiers and initial equations.

So in your example x(0) would be equal to 7 whatever was computed in the initial equation section. When re-simulating, the model would behave exactly as it would have a start=7 modifier or a x=7 initial equation.

In more general terms OM, when asked to re-simulate, at t=0 could first solve the model in the usual way (also considering initial equations and "start=xx" conditions), then override the obtained values with those existing in the Variables Browser: in this way, if the user has made some changes, they would be naturally taken into account. If the user has made no changes, this way OM would replace computed values with identical ones (this could make sense in some cases, e.g. when the user just changes the simulation time).

I'm not able to envisage any example having trouble with my idea.
And it has its advantage that it is very clearly and compactly stated (my italic sentence above).

[Martin Sjölund]

So basically, you want a totally different semantics for setting the start-value of a state-variable: after solving the initial equations, add an event and reinit the state variable to whatever you want to set. It's feasible, but you would end up with a result where some of the initial equations are ignored and the result-file would look a bit weird as a result of that.

[anonymous]

Well, I was thinking at the actions the user will do: change numbers and re-run. There is no long time in between, to that the user would have clear in his mind that he was partially overriding the results from initial equations.

But, actually, I don't really need this. I was just trying to envisage what is best for the final user, also having in mind the ease of implementation, and what this ticket text hints.

If nobody supports this idea, even Kral that opened this ticket, for me it is ok to drop it.
It was low priority, however.

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

I totally understand that overwriting the settings of initial variables may break the consistency of initial equations. The proposal of @anonymous to first initialize the model and then re-init the overwritten settings may be misleading in some cases but may be useful in other cases. In case of example

model ReSimulate2
  Real x, y;
initial equation
  x+y=2:
  x-y=0;
equation
  der(x)=1;
  der(y)=x;
end ReSimulate2;

consistency is broken, after overwriting the start value x=2.

Yet, in

model ReSimulate3
  Real x, y;
initial equation
  x=1:
  y=2;
equation
  der(x)=1;
  der(y)=x;
end ReSimulate3;

one can still have a consistent initial solution. My conclusion is, that the input of initial variables shall be disabled in case of ReSimulate2, but shall still be enabled in case of ReSimulate3.

If the discrimination of the two cases is too much effort, it could even be considered to to disable the start input field of all variables having initial equations, but keep all input fields of variables which use (start=...). I think it is important to not have an input field which has no impact -- which is misleading to the user, as well.

However, I like the feature of overwriting initial start values in the GUI of OpenModelica, so am very happy it's there. This feature is very useful.

[Adeel Asghar]

Willi can you manage the isValueChangeable field for the above cases?

[Willi Braun]

Replying to adeas31:

Willi can you manage the isValueChangeable field for the above cases?

I don't see a consensus here. In which cases should isValueChangeable changed?

Replying to Christian Kral:

My conclusion is, that the input of initial variables shall be disabled in case of ReSimulate2, but shall still be enabled in case of ReSimulate3.

I don't think it is helpful to disable it for ReSimulate2, because if the correspoding variable is an iteration variable of an algebraic loops(e.g. example from comment:6) it quite important to use start values and the possibility to change them.

I don't think this a bug, it is a misinterpretation of this value, it is just a start value and it is completely correct that it is ignored in the original model ReSimulate. Since it is without question that it should be ignored also in the following case:

model ReSimulate
  Real x(start=-273.15);
initial equation
  x=0;
equation
  der(x)=1;
end ReSimulate;

I tend to set to worksforme. Any other options?

[dr.christian.kral@…]

On my opinion the drawbacks of worksforme are:

• I yet think that allowing the user to enter a value to a field which does not cause the (conseuquently) anticipated change for the value, may be misleading to the user.
• So in a simple model case the user may even understand that the anticipated change cannot be performed without breaking the consistency of the model. Yer in a more complex model the user may not be able to fully understand the impact of one changed initial condition

Consequently I would still prefer disabling the option if a change has no impact on the consistent solution of the initial conditions -- isn't this a way to detect whether a change shall be enabled or not?

[Willi Braun]

Replying to dr.christian.kral@…:

On my opinion the drawbacks of worksforme are:

• I yet think that allowing the user to enter a value to a field which does not cause the (conseuquently) anticipated change for the value, may be misleading to the user.
• So in a simple model case the user may even understand that the anticipated change cannot be performed without breaking the consistency of the model. Yer in a more complex model the user may not be able to fully understand the impact of one changed initial condition

I my option the value to may edit there is just a start value, and I think Modelica users have to understand and how a start value influences the simulation run. An in fact in some case not at all.

Consequently I would still prefer disabling the option if a change has no impact on the consistent solution of the initial conditions -- isn't this a way to detect whether a change shall be enabled or not?

I'm not sure if the costs are worth to detect the influence of the start value by the initialization. In fact I doubt its always really possible. Maybe lochel has ideas, or is willing to do that, in the initialization phase.

[Christoph Buchner <buchner@…>]

To maybe add the perspective of a moderately skilled user, I would also be confused if I changed an editable field (which I until now understood to be parameters only), and nothing changed on resimulation.

Would it be technically feasible to differentiate between "real" editable parameters and start values in the GUI, e.g. with a differently coloured background in the textbox? If that is simple todo it might be a good middle ground?