Opened 9 years ago

Last modified 9 years ago

#3547 new defect

Initial event is not propagated as expected

Reported by: Bernhard Thiele Owned by: Lennart Ochel
Priority: normal Milestone: Future
Component: Initialization Version:
Keywords: Cc:

Description

Simulation of the model below results into the end values v2=1 as expected, but v1=0 (as opposed to the expected: v1=1).

model InitialEvent
  Boolean iev(start=false,fixed=true);
  Integer v1(start=0,fixed=true), v2(start=0,fixed=true);
equation
  iev = initial();
  when {iev} then
    v1 = pre(v1) + 1;
  end when;
  when {initial()} then
    v2 = pre(v1) + 1;
  end when;
end InitialEvent;

Change History (7)

comment:1 by Lennart Ochel, 9 years ago

That's what I expect as result. Just the second when clause is active during initialization, as written in the specification:

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.

comment:2 by Bernhard Thiele, 9 years ago

Yes, I found that, too. But my expectation was that it would also work if instead of initial() an alias event variable is used. Because this behaviour would be consistent with how event propagation works in similar cases, e.g., following model works as I expected (v1=1 and w1=1):

model InitIf
  Boolean iev(start=false,fixed=true), c, ev;
  Integer v1(start=0,fixed=true), w1(start=0,fixed=true);
equation
  iev = initial();
  v1 = if iev then pre(v1) + 1 else pre(v1);
  
  c = time > 0;
  ev = edge(c);
  when ev then
    w1 = pre(w1) + 1;
  end when;
end InitIf;

For me it is a counterintuitive exception to treat "initial()" in when-clauses like suggested by you (though I agree that the specification text suggests it). Is there any practical rationale behind that restriction?

in reply to:  2 comment:3 by Lennart Ochel, 9 years ago

Replying to bthiele:

For me it is a counterintuitive exception to treat "initial()" in when-clauses like suggested by you (though I agree that the specification text suggests it). Is there any practical rationale behind that restriction?

That's probably something to discuss on the Modelica trac.

comment:4 by Martin Sjölund, 9 years ago

Spec says:

Clarified that initial() can only be used in a restricted form as condition in a when-clause.

(The inital model is invalid and should be rejected.)

comment:5 by Martin Sjölund, 9 years ago

Also, when initial() is stupid and I see no reason to use it over initial equation :)

comment:6 by Bernhard Thiele, 9 years ago

ok, you were faster than me. I just wanted to ask if the first model should be rejected by the compiler.

So I guess no clarification from the spec is needed. It just would be a reasonable change in the spec to allow it? Or are there any technical reason for that restrictions that I overlooked?

in reply to:  5 comment:7 by Bernhard Thiele, 9 years ago

Replying to sjoelund.se:

Also, when initial() is stupid and I see no reason to use it over initial equation :)

I also see no reason except for convenience, e.g., if you have a model with a sampled controller that should start in steady-state you would do s.th. like

model SteadyStateInit
  Real ref, x, u;
  discrete Real dy;
equation 
  ref = if time < 5 then 1 else 2;
  der(x) = -2*x + dy;
  u = ref - x;
  when {initial(), sample(0.1,0.1)} then
    dy = pre(dy) + 0.5*u;
  end when;
initial equation 
  der(x) = 0;
  pre(dy) = dy;
end SteadyStateInit;

Hence, you don't have to replicate the controller logic in the initial equation section. It is useful, but providing different concepts to achieve the same doesn't make it easier to understand the language...

Note: See TracTickets for help on using tickets.