Issues with resimulate

[Francesco Casella]

A ​forum post notifies that there are issues with the resimulate feature of OMEdit that were not present in v. 1.14.1. Specifically, if you simulate Modelica.Fluid.Examples.Tanks.EmptyTanks, change tank1.level_start to 1.1 and re-simulate, tank1.level still starts from 1 m.

The weird thing is that this does not happen with other models. For example, I've been recently playing around a lot with models from ​https://github.com/casella/COVID19Control, where I change parameters such as Ir_0 that influence the initial value of some states, using the latest nightly build, which works just fine.

I'm not sure what is the difference between the two cases. In any case, this is a regression that should really be fixed for the 1.16.0 release.

[Adeel Asghar]

This is indeed a regression. I tested Modelica.Fluid.Examples.Tanks.EmptyTanks in 1.14 and is working as expected.

I made a small script of the problem. Something is wrong in the runtime. The same thing is working for other models as mentioned by @casella but not for Modelica.Fluid.Examples.Tanks.EmptyTanks.

[Karim Adbdelhak]

The problem is that the variable tank1.level originally would be initialized with tank1.level_start but there is an epsilon parameter to avoid a zero initialization called tank1.level_start_eps. It is defined in Modelica.Fluid.Vessels.OpenTank as

  final parameter SI.Height level_start_eps = max(level_start, Modelica.Constants.eps);

And the tank level properties are set as

  SI.Height level(stateSelect=StateSelect.prefer, start=level_start_eps)

Since level_start_eps is final it cannot change, i think this is just something the new frontend does correct now.

[Francesco Casella]

As far as I know, the meaning of final is spelled out in two places in the Specification.

The first is ​Sect. 7.2.3 of the Specification, which says:

The merging is hierarchical, and a value for an entire non-simple component overrides value modifiers for all components, and it is an error if this overrides a final prefix for a component, or if value for a simple component would override part of the value of a non-simple component. This regards the flattening in the front-end, not the behaviour at runtime.

The second is ​Sect 7.2.6, which says:

An element defined as final by the final prefix in an element modification or declaration cannot be modified by a modification or by a redeclaration. All elements of a final element are also final. [Setting the value of a parameter in an experiment environment is conceptually treated as a modification. This implies that a final modification equation (not value, editor's note) of a parameter cannot be changed in a simulation environment].

This second definition I think clearly settles down the issue, i.e. you cannot change the modification of the parameter binding, hence you cannot force a final parameter to get some value which is different from the one that can be computed from its binding equation. However, there is no mention whatsoever that its value cannot change. To the contrary, the above-mentioned statement implies that it should, if the bound expression is eventually a function of non-final parameters, because the binding equation cannot be overridden.

In this specific case, this means that it should not be possible to change directly the value of level_start_eps at runtime, but that any change applied to level_start should actually be passed on to the binding equation.

In principle, one could also directly change the start attribute of the level, since the start modifier is not final, but this is another story.

Solving this issue may still require some NF fixes, see #5390. There is also a possibly releated issue with OMEdit,see #5312.

[Karim Adbdelhak]

Replying to casella:

This second definition I think clearly settles down the issue, i.e. you cannot change the modification of the parameter binding, hence you cannot force a final parameter to get some value which is different from the one that can be computed from its binding equation. However, there is no mention whatsoever that its value cannot change. To the contrary, the above-mentioned statement implies that it should, if the bound expression is eventually a function of non-final parameters, because the binding equation cannot be overridden.

I was not really aware of this, but it makes a lot of sense.

After digging a little bit deeper trying to construct a minimal model, i found the actual problem. During homotopy initialization of the lambda=0 system we create hardcoded equations for the parameter bindings.

/*
equation index: 125
type: SIMPLE_ASSIGN
tank1.level_start = 1.0
*/
void Modelica_Fluid_Examples_Tanks_EmptyTanks_eqFunction_125(DATA *data, threadData_t *threadData)
{
  TRACE_PUSH
  const int equationIndexes[2] = {1,125};
  data->simulationInfo->realParameter[51] /* tank1.level_start PARAM */ = 1.0;
  TRACE_POP
}

I don't really know why that happens, for the normal initialization that does not happen.

Please see attached minimal.mos file. The first model M has the basic problem without homotopy and M2 uses homotopy. For the first the overwriting works and for the second it does not.

Anybody has a clue where a change like this could have happened?

[Karim Adbdelhak]

I found a fix. It is a classic de-synchronization problem between the initial and initial lambda-0 shared objects. I had to update the global known variables accordingly.

​PR967 fixes it, hopefully jenkins approves.

[Karim Adbdelhak]

It works, we will push it soon! I don't think anything else has to be done here.

[Francesco Casella]

Great, thanks!

I see that the PR was merged and @adeas31 confirmed it works fine on OMEdit. I also put a message on the forum post