Code generation of algorithm with enumeration indexed array fails while integer indexed array works fine

[Gustaf Thorslund]

Somehow trying to index an array with an enumeration type results code generation trying to solve a linear system and fail, while same test with integer indexed array works fine. The following code have one model for each case:

package ArrayTest
  constant Integer N = 3;
  type E = enumeration (e1, e2, e3);
  type AI = Real[N];
  type AE = Real[E];

  function printArray
    input Real a[:];
  algorithm
    for i loop
      print(" " + String(a[i]));
    end for;
    print("\n");
  end printArray;
  
  model IntIndex
    AI x;
  initial algorithm
    for i loop
      x[i] := 0;
    end for;
  algorithm
    when sample(0,0.1) then
      for i loop
	x[i] := time;
      end for;
      printArray(x);
    end when;
  end IntIndex;

  model EnumIndex
    AE x;
  initial algorithm
    for i loop
      x[i] := 0;
    end for;
  algorithm
    when sample(0,0.1) then
      for i loop
	x[i] := time;
      end for;
      printArray(x);
    end when;
  end EnumIndex;
end ArrayTest;

Trying the integer indexed model works just fine:

$ omc -s ArrayTest.mo -i=ArrayTest.IntIndex -d=failtrace
function ArrayTest.printArray
  input Real[:] a;
algorithm
  for i in 1:size(a, 1) loop
    print(" " + String(a[i], 0, true, 6));
  end for;
  print("
  ");
end ArrayTest.printArray;

class ArrayTest.IntIndex
  Real x[1];
  Real x[2];
  Real x[3];
initial algorithm
  for i in 1:3 loop
    x[i] := 0.0;
  end for;
algorithm
  when sample(0.0, 0.1) then
    for i in 1:3 loop
      x[i] := time;
    end for;
    ArrayTest.printArray({x[1], x[2], x[3]});
  end when;
end ArrayTest.IntIndex;

$ make -f ArrayTest.IntIndex.makefile

$ ./ArrayTest.IntIndex 
 0 0 0
 0.1 0.1 0.1
 0.2 0.2 0.2
 0.3 0.3 0.3
 0.4 0.4 0.4
 0.5 0.5 0.5
 0.6 0.6 0.6
 0.7 0.7 0.7
 0.8 0.8 0.8
 0.9 0.9 0.9
 1 1 1

The enumeration indexed array will on the other hand result in errors during code generation.

$ omc -s ArrayTest.mo -i=ArrayTest.EnumIndex -d=failtrace
function ArrayTest.printArray
  input Real[:] a;
algorithm
  for i in 1:size(a, 1) loop
    print(" " + String(a[i], 0, true, 6));
  end for;
  print("
  ");
end ArrayTest.printArray;

class ArrayTest.EnumIndex
  Real x[ArrayTest.E.e1];
  Real x[ArrayTest.E.e2];
  Real x[ArrayTest.E.e3];
initial algorithm
  for i in ArrayTest.E.e1:ArrayTest.E.e3 loop
    x[i] := 0.0;
  end for;
algorithm
  when sample(0.0, 0.1) then
    for i in ArrayTest.E.e1:ArrayTest.E.e3 loop
      x[i] := time;
    end for;
    ArrayTest.printArray({x[ArrayTest.E.e1], x[ArrayTest.E.e2], x[ArrayTest.E.e3]});
  end when;
end ArrayTest.EnumIndex;
Error: When solving linear system 
1 : $PRE.x[ArrayTest.E.e1] = x[ArrayTest.E.e1]
2 : x[ArrayTest.E.e1] = $PRE.x[ArrayTest.E.e1]
[
  -1.0 , 1.0 ;
  1.0 , -1.0
]
  *
[
  x[ArrayTest.E.e1] ;
  $PRE.x[ArrayTest.E.e1]
]
  =
[
  -0.0 ;
  -0.0
]
  U(2,2) = 0.0, which means system is singular for variable $PRE.x[ArrayTest.E.e1].
[/home/gustaf/src/openmodelica/Compiler/BackEnd/BackendDAETransform.mo:445:7-445:48:writable] Error: Internal error BackendDAETransform.analyseStrongComponentBlock failed
variables:
  x[ArrayTest.E.e1]
  $PRE.x[ArrayTest.E.e1]
equations:
  $PRE.x[ArrayTest.E.e1] = x[ArrayTest.E.e1]
  x[ArrayTest.E.e1] = $PRE.x[ArrayTest.E.e1]
[/home/gustaf/src/openmodelica/Compiler/BackEnd/BackendDAETransform.mo:449:7-449:90:writable] Error: Internal error function analyseStrongComponentBlock failed
[/home/gustaf/src/openmodelica/Compiler/BackEnd/BackendDAETransform.mo:106:5-106:111:writable] Error: Internal error function strongComponentsScalar failed (sorting strong components)
[/home/gustaf/src/openmodelica/Compiler/BackEnd/BackendDAEUtil.mo:7193:5-7193:89:writable] Error: Internal error Transformation module sort components failed
Error: No system for the symbolic initialization was generated.

Since the variable x is only referred inside an algorithmic section I see no reason to solve a linear system for it.

[Per Östlund]

Despite what I told you earlier I had a quick look, and think I know what the issue is. The back end doesn't handle enum ranges well, but I'll fix that.

[Per Östlund]

Fixed in r25037. There still seems to be some remaining issue though, because you now get warnings that the initial conditions are both not fully specified and over specified. But the model can be simulated and gives the expected result.

I found another place in the back end which doesn't handle enumeration ranges that I'm going to fix also, maybe that's related to the issue with the initial conditions. But I'm not sure if I'll have time to fix it today.

[Gustaf Thorslund]

I found other issues with enumeration too, so I created ticket #3213.

[Per Östlund]

Replying to perost:

I found another place in the back end which doesn't handle enumeration ranges that I'm going to fix also, maybe that's related to the issue with the initial conditions. But I'm not sure if I'll have time to fix it today.

Fixed in r25063, but it made no difference for this model. I can't see any other obvious places in the back end where converting enums to ints may cause issues though.

[Gustaf Thorslund]

Changing the initialization of the model removes the initial condition issue.

test/ArrayTest.mo

@@ -14 +14 @@
   end printArray;
   
   model IntIndex
-    AI x;
-  initial algorithm
-    for i loop
-      x[i] := 0;
-    end for;
+    AI x(each start=0, each fixed=true);
   algorithm
     when sample(0,0.1) then
       for i loop
@@ -29 +25 @@
   end IntIndex;
 
   model EnumIndex
-    AE x;
-  initial algorithm
-    for i loop
-      x[i] := 0;
-    end for;
+    AE x(each start=0, each fixed=true);
   algorithm
     when sample(0,0.1) then
       for i loop

I think the issue of the initial conditions should be considered in some other ticket instead.

[Per Östlund]

Initialization issues fixed in r25085.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.