error type: error when building simulator

[Adrian Pop]

Hello!
I have already sent you another question a couple of hours ago. Here comes the next one:

The error message that shows is

"error when building the simulator
gcc -falign-functions -msse2 -mfpmath=sse -I"C:/Users/SRL1LO/Downloads/OpenModelica/build/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o example2.testmodel.o example2.testmodel.c

gcc -falign-functions -msse2 -mfpmath=sse -I"C:/Users/SRL1LO/Downloads/OpenModelica/build/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o example2.testmodel_functions.o example2.testmodel_functions.c

gcc -falign-functions -msse2 -mfpmath=sse -I"C:/Users/SRL1LO/Downloads/OpenModelica/build/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o example2.testmodel_records.o example2.testmodel_records.c

gcc -falign-functions -msse2 -mfpmath=sse -I"C:/Users/SRL1LO/Downloads/OpenModelica/build/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o example2.testmodel_01exo.o example2.testmodel_01exo.c

example2.testmodel.c: In function 'example2_testmodel_eqFunction_3':

example2.testmodel.c:115: error: expected expression before 'modelica_integer'

example2.testmodel.c:115: error: expected ')' before '$Pi$rB$Psignal'

mingw32-make: * [example2.testmodel.o] Error 1

mingw32-make: * Waiting for unfinished jobs.... "

As in the previously sent model,I simplified a complexe model to better show the problem.

Please simulate "testmodel" that can be found in the package "example2".

The type used in the package consists of an integer(signal) and of an enumeration (dataType), that represents the datatype of the integer.
An input (InputConnector), output (OutputConnector) and a source of that type can be found in the package aswell.

[Lennart Ochel]

This is of course a problem with the code generation for arrays:

/*
 equation index: 1
 type: ALGORITHM
 
   writeSomeOutput.outputConnector := example2.OutputConnector(source.signal, source.signalType);
   for i in 1:2 loop
     if not writeSomeOutput.inputConnector[i].signal == 0 then
       writeSomeOutput.outputConnector.signal := 1 + writeSomeOutput.outputConnector.signal;
     end if;
   end for;
 */

The algorithm section from above gets tgranslated to the following wrong c code:

  $PwriteSomeOutput$PoutputConnector$Psignal = tmp0._signal;
  $PwriteSomeOutput$PoutputConnector$PsignalType = tmp0._signalType;

  tmp2 = (modelica_integer) 1; tmp3 = 1; tmp4 = (modelica_integer) 2;
  if(!tmp3)
  {
    FILE_INFO info = omc_dummyFileInfo;
    omc_assert(threadData, info, "assertion range step != 0 failed");
  }
  else if(!(((tmp3 > 0) && (tmp2 > tmp4)) || ((tmp3 < 0) && (tmp2 < tmp4))))
  {
    modelica_integer $Pi;
    for($Pi = (modelica_integer) 1; in_range_integer($Pi, tmp2, tmp4); $Pi += tmp3)
    {
      if((!((modelica_integer)$PwriteSomeOutput$PinputConnector$lB(modelica_integer)$Pi$rB$Psignal == (modelica_integer) 0)))
      {
        $PwriteSomeOutput$PoutputConnector$Psignal = ((modelica_integer) 1 + (modelica_integer)$PwriteSomeOutput$PoutputConnector$Psignal);
      }
    }
  }

Please note the following if condition from above:

if((!((modelica_integer)$PwriteSomeOutput$PinputConnector$lB(modelica_integer)$Pi$rB$Psignal == (modelica_integer) 0)))

[Lennart Ochel]

Mahder, please can you have a look?

[Mahder Alemseged Gebremedhin]

So this happens for a very specific case. That is when we have:

• An algorithm section in a model (I mean the flattened model. so sections from blocks count too if the block is used.)
• A for loop in the algorithm section
• An array indexing in the body of the for loop using the loop iterator
• The indexed array is part of a qualified path but not the last identifier i.e. a.b[i] is okay but a[i].b causes the problem.

The reason is that we use the macro definitions to refer to simulation variables. Since every array is vectorized in a model, and all indexing values known (apart from the implicitly declared ) every element of the array is referred to directly. e.g. for

a[1].b

we get

$P_a_$lB_1_$rB_$P_b

Obviously this won't work if we have indexes like i instead of integer literals like 1 or 0 since

$P_a_$lB_i_$rB_$P_b

is not defined as a macro and can't be since i is not know until run-time.

The case where the array indexing is at the end of a qualified name

a.b[i]

is okay because the elements a.b[1] a.b[2] ... lie in contagious memory locations. Which means we can use pointer arithmetic

&a.b[0] + i

to access a.b[i].

It might be possible to do the for the previous cases as well but that would be a very strict restriction on how you sort and generate variable orders in the back end. It would probably introduce more problems than it solves.

---

This doesn't happen for loops in equation sections because those are always unrolled or vectorzed.

---

The simplest workaround is to just unroll the loop in the source code

for i in 1:2 loop
  if not (inputConnector[i].signal==0) then
    outputConnector.signal := outputConnector.signal+1;
  end if;
end for;

to

if not (inputConnector[1].signal==0) then
  outputConnector.signal := outputConnector.signal+1;
end if;
if not (inputConnector[2].signal==0) then
  outputConnector.signal := outputConnector.signal+1;
end if;

or something similar. Just try to avoid the combination of the points at the top.

---

The simplest fix is to detect loops in algorithm sections in models and unroll them. This might make the generated code large if the loops have large iterations. However I don't think suck loops in algorithm sections are common so this might work.

I think I will do that.

[anonymous]

I am afraid this solution will not work for me as the loop from 1 to 2 is a strong simplification of my model.
The loop size (in this case 2) changes and can be a much larger number than two.
Therefore it would be good to fix this problem.

[Per Östlund]

#2688 might be related.

[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]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[Per Östlund]

This seems to have been fixed at some point, the model now simulates.