Variable of matrix element accessed by enumeration value not replaced in C-Code

[Patrick Täuber]

Please consider the following model:

model foo
  Real x;
  parameter Real m[2]={1,2};
  type enum = enumeration(index1, index2);
equation
  x = m[enum.index1];
end foo;

It leads to the following compilation errors:

foo_06inz.c:50:54: error: use of undeclared identifier '$Pm$lB1$rB'
  data->localData[0]->realVars[0] /* x variable */ = $Pm$lB1$rB;

foo.c:105:54: error: use of undeclared identifier '$Pm$lB1$rB'
  data->localData[0]->realVars[0] /* x variable */ = $Pm$lB1$rB;

[Willi Braun]

Strange, slightly changed and it works:

model foo
  Real x;
  parameter Real m[enum]={1,2};
  type enum = enumeration(index1, index2);
equation
  x = m[enum.index1];
end foo;

[Willi Braun]

The code generation issue is raised by a the fact that we try to search for a variable with the name : m[enum.index1], but we know only m[1] and m[2].

So the actually issue is that we do not replace "enumeration literals" by it's constants.
I guess we could do that already in the Frontend, or?

[Martin Sjölund]

No, we need to never replace the index until code generation for readability of the code.

[Martin Sjölund]

And reading the C-code, isn't the problem that we replaced it with m[1] but we only know the variable including the enum? Either way, during code generation we could replace enum literals with integers for the hash tables, etc.

[Willi Braun]

Replying to sjoelund.se:

No, we need to never replace the index until code generation for readability of the code.

But the readability will be improved, if the literals are replaces by integers.

[Willi Braun]

Replying to sjoelund.se:

And reading the C-code, isn't the problem that we replaced it with m[1] but we only know the variable including the enum? Either way, during code generation we could replace enum literals with integers for the hash tables, etc.

No, we actually do not replace m[enum.index1] it's just the old crefDefine function that outputs that as error case actually ;)

[Willi Braun]

Replying to sjoelund.se:

And reading the C-code, isn't the problem that we replaced it with m[1] but we only know the variable including the enum? Either way, during code generation we could replace enum literals with integers for the hash tables, etc.

The problem raises if we mix the expressions, like here:

model foo
  Real x,y;
  parameter Real m1[enum]={1,2};
  parameter Real m2[2]={1,2};
  encapsulated type enum = enumeration(index1, index2);
equation
  x = m1[enum.index1]+sin(time)*m1[2];
  y = m2[enum.index2]*sin(time)+m2[1];
end foo;

So actually we have to replace, either in the simCode phase or before. And I would prefer to do that as soon as possible.

[Martin Sjölund]

m1[2] is not valid Modelica and can never appear (it is outside the bounds enum.index1:enum.index2).

[Willi Braun]

okay, but is then m2[enum.index2] also invalid, since it is outside of the bounds of 1:2?

[Martin Sjölund]

Yes, it is invalid. You have to use Integer(enum.index2) explicitly.

[Willi Braun]

Okay, make sense. Then the model in the ticket is also invalid and we have no issue :).

[Martin Sjölund]

We do if the frontend accepts it :)