Add option to save intermediate values at event iterations to result files?

[bthiele]

There already exists the option to save values at events. If one has event iterations it also would be interesting to see the values at intermediate events in an event iteration. E.g., the model below starts an event iteration at time > 2 that results in the output

D x: 2
A x: 5
B x: 6

but in the (csv) result file at t=2 there are only two entries (x=2 and x=6).

model WhenPriority
 import S = Modelica.Utilities.Streams;
 Integer x(start=0,fixed=true);
equation
  when pre(x) == 2 then
    S.print("A x: "+String(x));
    x = pre(x) + 3;
  elsewhen pre(x) > 4 then
    S.print("B x: "+String(x));
    x = pre(x) + 1;
  elsewhen pre(x) > 3 then
    S.print("C x: "+String(x));
    x = pre(x) + 2;
  elsewhen time > 2 then
    S.print("D x: "+String(x));
    x = 2;
  end when;
end WhenPriority;

Of course that doesn't improve the insight to the model if plotting the variable with current OMPlot, but "customized" visualization solutions could profit from it and even try to visualize the event order.

[lochel]

I'm not sure if that need be dumped into the result file. However if that would be needed, it is no problem to implement it.
I think the event dumps (LOG_EVENTS/LOG_EVENTS_V) need to be improved.

$ ./test –lv=LOG_EVENTS
LOG_EVENTS        | info    | status of relations at time=0
|                 | |       | | [1] (pre: false) false = time > 2.0
LOG_EVENTS        | info    | status of zero crossings at time=0
|                 | |       | | [1] (pre:  0) -1 = time > 2.0
LOG_EVENTS        | info    | state event at time=2.0000000003
|                 | |       | | [1] time > 2.0
stdout            | info    | D x: 2
stdout            | info    | A x: 5
stdout            | info    | B x: 6

Above is the simulation output listed using -lv=LOG_EVENTS. I think it would be good to include also the event iteration into this dump. What do you think?

[bthiele]

Replying to lochel:
I agree that the event logging should be improved to also include event iteration. I'm actually surprised that it is currently not shown, since it is an important information when debugging.

I just checked for another tool's output when logging events and found it quite nice since it even includes the variable that was changed during the event:

Expression time > 2 became true ( (time)-(2) = 1e-10 )
  Variable x = 2 at time 2
Iterating to find consistent restart conditions.
  Variable x = 5 at time 2
Iterating to find consistent restart conditions.
  Variable x = 6 at time 2
Iterating to find consistent restart conditions.
      during event at Time :  2.0000000001

But the information that you get from the event log is more intended for debugging purposes. Including it in the result file would be not only for debugging. The values that a variable becomes during event iteration can be seen as an integral part of the evolution of hybrid systems, particularly considering hybrid system semantics approaches such as super-dense time or non-standard time modeling.

However, I'm not sure whether simply adding such intermediate points to the result file is already good enough or whether one should search for better alternatives right away. Particularly, if one considers clocked variables a more sophisticated approach is desirable, since signals can be absent on some clocks and that should show up in the result file, too.