How can binded blocks produce top-level inputs?

[Lennart Ochel]

I found some issues using blocks. OpenModelica cannot simulate the model test from the following package.

package bug_2213
  block anyChange "does any entry of a boolean vector change its value?"
    input Boolean vec[:];
    output Boolean anychange;
  algorithm
    anychange:=false;
    for i in 1:size(vec, 1) loop
      anychange:=anychange or change(vec[i]);
    end for;
  end anyChange;

  model test
    Boolean b[3];
    anyChange ac(vec=b);
    Integer i(start=0, fixed=true);
  equation
    b[1] = time > 0.1;
    b[2] = time > 0.2;
    b[3] = time > 0.3;

    when ac.anychange then
      i = pre(i) + 1;
    end when;
  end test;
end bug_2213;

Already our flat code seems to be weird. Why do we get top-level inputs in the flat code?

class bug_2213.test
  Boolean b[1];
  Boolean b[2];
  Boolean b[3];
  Integer i(start = 0, fixed = true);
  input Boolean ac.vec[1];
  input Boolean ac.vec[2];
  input Boolean ac.vec[3];
  output Boolean ac.anychange;
equation
  ac.vec = {b[1], b[2], b[3]};
  b[1] = time > 0.1;
  b[2] = time > 0.2;
  b[3] = time > 0.3;
  when ac.anychange then
  i = 1 + pre(i);
  end when;
algorithm
  ac.anychange := false;
  for i in 1:3 loop
    ac.anychange := ac.anychange or change(ac.vec[i]);
  end for;
end bug_2213.test

[Lennart Ochel]

Same question for top-level outputs.

[Lennart Ochel]

The following listing shows the flat Modelica code generated with Dymola:

model bug_2213.test

Boolean b[3];
Boolean ac.vec[:] = b;
Boolean ac.anychange;
Integer i(start = 0, fixed = true);

// Equations and algorithms

  // Component ac
  // class bug_2213.anyChange
  algorithm
    ac.anychange := false;
    for i in (1:size(ac.vec, 1)) loop
      ac.anychange := ac.anychange or change(ac.vec[i]);
    end for;

  // Component 
  // class bug_2213.test
  equation
    b[1] = time > 0.1;
    b[2] = time > 0.2;
    b[3] = time > 0.3;
    when ac.anychange then
      i = pre(i)+1;
    end when;

end bug_2213.test;

There are no inputs/outputs as expected.

[Lennart Ochel]

This is probably only a dumping issue, because the numbers of equation and variables seems to be okay for the backend.

The main problem is that this model cannot be simulated. This is obviously not a frontend but rather a codegen bug. The model contains a variable named i that has the same name than a temp. generated iteration variable in the c-source (see #2214).

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

As of v1.13.0-dev-155-g68350e9, the weird input qualifiers are gone from the flattened model:

class P.test
  Boolean b[1];
  Boolean b[2];
  Boolean b[3];
  Boolean ac.vec[1];
  Boolean ac.vec[2];
  Boolean ac.vec[3];
  Boolean ac.anychange;
  Integer i(start = 0, fixed = true);
equation
  ac.vec = {b[1], b[2], b[3]};
  b[1] = time > 0.1;
  b[2] = time > 0.2;
  b[3] = time > 0.3;
  when ac.anychange then
    i = 1 + pre(i);
  end when;
algorithm
  ac.anychange := false;
  for i in 1:3 loop
    ac.anychange := ac.anychange or change(ac.vec[i]);
  end for;
end P.test;

However, the simulation fails at initialization with

assert | error | <p>Dimension 1 has bounds 1..3, got array subscript 0</p>
assert | info | <p>simulation terminated by an assertion at initialization</p>

so, there is probably something wrong in codegen.