Wrong reference files for Modelica_Synchronous

[rfranke]

Some of the remaining verification failures are due to wrong reference files. In particular the models that start to tick after initial simulation time:

Modelica_Synchronous.Examples.Elementary.BooleanSignals.BackSample
Modelica_Synchronous.Examples.Elementary.IntegerSignals.Hold
Modelica_Synchronous.Examples.Elementary.RealSignals.BackSample
Modelica_Synchronous.Examples.Elementary.RealSignals.Hold

Take the latter as example. See:
​https://test.openmodelica.org/libraries/Modelica_Synchronous_cpp/files/Modelica_Synchronous.Examples.Elementary.RealSignals.Hold.diff.shiftSample.y.html

The reference has the initial value of 0 for shiftSample.y (with the alias hold.u). The Cpp runtime produces -1. This is y_start of the connected hold model. The model explicitly states: hold.u(final start=y_start).

The Modelica spec states in a similar case for accessing a not yet calculated value: "The operator previous(xd) returns the value of xd at the previous clock tick. At the first sample instant, the start value of xd is returned."

[bthiele]

I just looked into the Modelica_Synchronous.Examples.Elementary.RealSignals.Hold example.

The difficulty is that the clock of shiftSample.y is not active before t=40ms, hence there is no value for that signal during t<40ms. Actually, we should to test for the absence/presence of a clocked value, but we currently have no support for it.

The quoted Modelica spec statement is not really applicable here since it also requires a clock tick at the instant where the variable value is observed.

I see the problem, but I think the correct way to handle it would be to be able to test for the absence/presence of clocked values.

[rfranke]

The definition of clocked variables only having values at clock ticks is important for the formal model analysis. Nevertheless each clocked variable is implemented as a variable that has a value at any time. It is questionable how much the whole implementation needs to be changed for clocked variables. The intended FMI extension, for instance, assumes an implicit hold for each clocked output.

So, what is wrong with assigning start values to variables at simulation start?

Do we possibly need to add a clarification to the Modelica 3.3 standard for this?

[rfranke]

See the following example:

model DelayedFirstTick
   Real x(start = -1);
   Real x_hold;
   Clock c = shiftSample(Clock(1, 10), 2);
equation 
   x = sample(sin(time), c);
   x_hold = hold(x);
end DelayedFirstTick;

Here x_hold has the initial value of -1 betwenn time 0 and 0.2. This value comes from x. This is why x must have the initial value of -1 before the first clock tick.

The reference files say that x has the initial value of 0 though!?

[bthiele]

Yes, but what is the value of a clocked variable if its associated clock is not active? Without additional assumption like "implicit hold" one just cannot observe the variable during these times.

This view can have advantages during code generation, since such variables can be translated into local variables instead of state variables. One of the rationals given in the MLS for clocked variables is (p.191):

Due to the automatic sample and hold semantics, all variables assigned in a when-clause of the above kind
must have an initial value because they might be used, before they are assigned a value the first time. As a
result, all these variables are “discrete-time states” although in reality only a small subset of them need an
initial value.

In your example one would need to introduce a memory because of the hold(..) operator and we need an initial value for it. This value is taken from the start-value of the input argument to the hold operator (an alternative language design choice could have been to give the initial value as a second argument to the hold operator). Adapting this view, it is not required to postulate an initial value for x.

However, practically we would like some way to compare results generated by different tools and one needs to agree on how to handle this cases when clock variables are not active. To assume an implicit hold for clocked variables and use the "start" value of that variable before its clock ticks the first time is one possibility. Just setting a variable to "0" before its first clock tick is another possibility.

Maybe get opinions from other tool vendors during the next Modelica Design meeting?

[rfranke]

I'd like to see it simpler: hold(x) produces a value at any time, also before the first clock tick for x. This means that x must have a value before the first clock tick. This value is specified with the start attribute -- no matter if its a state or an auxiliary variable. Dymola and OpenModelica both produce the same result.

So why not correcting the reference files?

[bthiele]

I used Dymola generated result files and filtered out the reference variables that are used in the tests. I will need to change the files manually. I already had a go using python to read, change and write the files. Unfortunately the python scipy.io.savemat(.., .., format='4') function seems to store the matrices in a way that OM cannot access anymore. It should be the correct mat file version, but it seems that Python switches the order of matrices and the matrices have to be stored in a particular order for OM.

I'll have another go at some later time, maybe installing and trying with Matlab, or are there any recommendation how to manually modify this mat files?

[anonymous]

Dymola: export as txt. edite txt. load txt, save as mat.

[rfranke]

It looks good now. Thank you for the update reference files!
(​https://github.com/OpenModelica/OpenModelica-testsuite/commit/a06417423e16671b21e18cddc92f888e5452f942)

There was another bug that prevented coverage from going up today. Should be fine tomorrow.
(​https://github.com/OpenModelica/OMCompiler/commit/23bb6ec070e33fff16f05096d2b7db08c0c345a0)