Event handling at time=startTime

[Lennart Ochel]

What is the expected result for y at time=startTime (not at initialization)? Probably this get handled wrongly by OpenModelica.

model foo
  Real x, y;
equation 
  x = if initial() then 0.0 else 1.0;

  when sample(0.0, 1.0) then
    y = pre(x) + 1;
  end when;
end foo;

[Bernhard Thiele]

At first glance I would expect y=1.0 at t=0.0, but currently simulation in OM results in y=2.0 at t=0.0.

On a second thought, x is a discrete Real variable and can only change at events. Hence, we need an event for changing x from 0.0 to 1.0. This event needs to be triggered directly after initialization. But also sample(0.0, 1.0) needs to be fired directly after initialization. Hence, it seems we have two independent events that occur at exactly the same time instant. Since there is no explicit synchronization between the events there is no guarantee regarding their scheduling order. So both, y=1.0 or y=2.0 should be correct values. What do you think?

[Lennart Ochel]

Replying to bthiele:

What do you think?

I agree with your analysis.

[Martin Sjölund]

The equations of a when-clause are active during initialization, if and only if they are explicitly enabled with the initial() operator; and only in one of the two forms when initial() then or `when {...,initial(),...}

then`

So during initialization, the when-statement is NOT active. So x=0.0, pre(x)=x. y is not specified (should use fixed=true). A tool should guess y=0.0 at initialization.

The next step may be t=0.0 or e.g. t=0.01. Since there is a time event at 0, I guess we should choose it. Then the result of that step should be x=1.0, y=1.0.

Right?

[Lennart Ochel]

Replying to sjoelund.se:

Right?

There are two time events for t=0. The first one (initial) updates x/pre(x) and the second one (sample) updates y/pre(y). Using dependency analysis it would be possible to define a order for both event, but that is not in the specification. Hence, I think Bernhard’s analysis is right, and there are two valid solution according to the specification.

[Martin Sjölund]

The order is already defined, because they are different phases. One is for the initialization. The second event is for continuous integration, and at this time the initial equations are no longer used.

During the initial step there is no event iteration, because there are no events. So x=pre(x)=0.

Check for example:

$ ./foo -override stopTime=0 -output x,y
time=0,x=1,y=0

Note: if initial() is illegal, so the model is bad. The if initial() should not generate an event since it should be a when initial() (which is just defining x=0 or x=1 depending on if it is initialization or not).

[Bernhard Thiele]

Replying to sjoelund.se:
Why is if initial() bad, is it forbidden by the specification?

I find that construct used in the MSL, see Modelica.Blocks.Continuous.LimIntegrator and also in examples of books teaching Modelica...

[Lennart Ochel]

If initial() isn’t forbidden. It generates a time event at time=startTime (for simulation of course). That’s at least what is in the specification.

[Lennart Ochel]

Modelica specification, section 3.7.3: Event-Related Operators with Function Syntax
initial(): Returns true during the initialization phase and false otherwise [thereby triggering a time event at the beginning of a simulation].

---

I think what Martin has in mind is the restriction on when initial() to activate a when clause for the initialization process.

[Bernhard Thiele]

Replying to sjoelund.se:

The order is already defined, because they are different phases. One is for the initialization. The second event is for continuous integration, and at this time the initial equations are no longer used.

During the initial step there is no event iteration, because there are no events. So x=pre(x)=0.

Can't fully follow your argument. Do you mean x=pre(x)=0 for all time or only during initialization?

Initial is defined in the MLS 3.3, Section 3.7.3 as:
initial(): Returns true during the initialization phase and false otherwise [thereby
triggering a time event at the beginning of a simulation].

So we should have an event if the condition initial() changes to false. That event is also needed to change the value of x discontinuously within an if-expression. Otherwise, we would have a situation that seems similar to having something like if noEvent(event) then 0.0 else 1.0. So for me having an event here seems reasonable. However, the result of Dymola for that model y=1 at startTime (and changes to y=2 at time=1). I tried to figure out whether Dymola creates an event for the if-equation, but I'm not completely sure what it does.

[Martin Sjölund]

So the problem is:

There is no guarantee that two different events occur at the same time instant.

I.e. Dymola may detect that /*not*/ initial() and sample(0, x) occur at the same time (they are both time events?), and thus might merge them as one event? Then no sorting is necessary.

[Bernhard Thiele]

Yes, that would be a reasonable explanation for what I observed in Dymola.

[Bernhard Thiele]

Replying to lochel:
Can we close this ticket?

[Lennart Ochel]

Conclusion: There is no unique solution.

[Dietmar Winkler]

Sorting these closed tickets away from "Future". Since they were closed after the last 1.9.3 release, it's very likely that they should have been part of the 1.9.4 release.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed