NF crashes when flattening algorithm with inconsistent types

[crupp@…]

The following model crashes omc when flattening using -d=newInst.

model crashbug

function func
  input Real a[4];
  output Real[4] A;
algorithm
  // This crashes omc
  A := sum(a for i in 1:4);
  //
  // This does not crash omc
//  A := zeros(4);
//  for i in 1:4 loop
//    A := A + a;
//  end for;

end func;

  parameter Real a[4] = zeros(4);
  parameter Real A[4] = func(a);

end crashbug;

Tested using OpenModelica nightly v1.16.0-dev-3-g6f27fe142a. I'm not sure what is causing this, so please modify the ticket summary as needed.

[Francesco Casella]

@crupp, thanks for reporting.

The crash takes place already when trying to flatten the model. I guess the problem is due to some type incompatibility in the line A := sum(a for i in 1:4);, since the left-hand side is an array of four Reals, while the right-end side is a scalar.

[crupp@…]

The right hand side is not a scalar, it's a vector. The crash also happens with:

A := sum(a[:] for i in 1:4);

The problem originated in a much more complex model that eventually sums the columns of an array.

[Karim Adbdelhak]

I actually don't quite understand, is this modelica language viable?

The modelica language specification states, that the sum operator sums over all elements, so it always returns a scalar:

sum(A) Returns the sum of all the elements of array expression A

I guess this is also true for multiple array inputs. Does your model work as you would expect in other modelica tools?

[crupp@…]

Works fine on old frontend. No, I haven't tried with another tool, but a crash is a crash.

For clarification, this also crashes (summing the columns of a):

model crashbug

function func
  input Real a[4,4];
  output Real[4] A;
algorithm

  A := sum(a[:,i] for i in 1:4);

end func;

  parameter Real a[4,4] = zeros(4,4);
  parameter Real A[4] = func(a);

end crashbug;

From what I can tell there is no conflict with the spec. There is a second function definition for sum:

sum(e(i, ..., j) for i in u, ..., j in v)

"The type of sum(e(i, ..., j) for i in u, ..., j in v) is the same as the type of e(i,...j)."

[Karim Adbdelhak]

Replying to crupp@…:

From what I can tell there is no conflict with the spec. There is a second function definition for sum:

sum(e(i, ..., j) for i in u, ..., j in v)

"The type of sum(e(i, ..., j) for i in u, ..., j in v) is the same as the type of e(i,...j)."

Seems reasonable, if no dimension is specified it just sums over the last one. I guess the problem is that

a[:,j] for j in 1:2

yields

{a[:,1], a[:, 2]}

which is processed as a concatenation of matrices and therefore multi dimensional, whereas

a[:] for j in 1:2

yields

{a[:], a[:]}

which is processed as a concatenation of vectors. This seems to be done such that the one existing dimension is expanded instead of creating a new one.

{a[1], a[2], ..., a[1], a[2], ...}

I am not really sure, it seems like there is always one to few dimensions counted. But maybe @perost or @mahge know.

[Per Östlund]

Replying to Karim.Abdelhak:

I am not really sure, it seems like there is always one to few dimensions counted. But maybe @perost or @mahge know.

The NF crashes due to an uninitialized variable somewhere. I will fix it.

[Per Östlund]

Fixed in ​PR #540.

[Per Östlund]

Merged in 5121fa3.

[Francesco Casella]

Replying to crupp@…:

The right hand side is not a scalar, it's a vector.

Of course it is, that's what happens when you process tickets very late in the day :)

Anyway, problem solved.