OM reports an error in the C code it creates

[massimo ceraolo]

If I run (using OM r20199) "gridTest21" of the enclosed package "AutoCreateBug" I get the following message:

"C:\Programmi\OpenModelica1.9.1Nightly\\MinGW\bin\mingw32-make.exe" -f AutoCreateBug.gridTest21.makefile
gcc   -falign-functions -msse2 -mfpmath=sse     -I"C:/Programmi/OpenModelica1.9.1Nightly//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME  -c -o AutoCreateBug.gridTest21.o AutoCreateBug.gridTest21.c
AutoCreateBug.gridTest21.c: In function 'AutoCreateBug_gridTest21_eqFunction_27':
AutoCreateBug.gridTest21.c:458: error: expected expression before 'modelica_integer'
AutoCreateBug.gridTest21.c:458: error: expected ')' before '$Pi$rB$Pv'
AutoCreateBug.gridTest21.c:460: error: expected expression before 'modelica_integer'
AutoCreateBug.gridTest21.c:460: error: expected ')' before '$Pi$rB$Pv'
mingw32-make: *** [AutoCreateBug.gridTest21.o] Error 1
Compilation process exited with code 2

It seems that OM creates for this model a C file that is invalid.

[Lennart Ochel]

The model fails for the generated code of the following algorithm:

equation index: 54
 type: ALGORITHM
 
   gridOneTrack.lostPower := 0.0;
   for i in 1:2 loop
     gridOneTrack.lostPower := gridOneTrack.lostPower + gridOneTrack.resisLeft[i].v * gridOneTrack.resisLeft[i].i;
     gridOneTrack.lostPower := gridOneTrack.lostPower + gridOneTrack.resisRight[i].v * gridOneTrack.resisRight[i].i;
   end for;

[massimo ceraolo]

I've modified the model code so that the algorithm that caused the issue (as shown by lochel in comment 4) is not there any-more.
The modified program works (AC_OM_Working.mo). Note that everything is correctly constant.

But at the slightest change, again the C code produced is invalid (AC_OM_NonWorking.mo).
Here's the error message I get using OM r22728:

AC_OM_NonWorking.gridTest21_05evt.c: In function 'AC_OM_NonWorking_gridTest21_function_ZeroCrossings':
AC_OM_NonWorking.gridTest21_05evt.c:93: error: '$Ptrain' undeclared (first use in this function)
AC_OM_NonWorking.gridTest21_05evt.c:93: error: (Each undeclared identifier is reported only once
AC_OM_NonWorking.gridTest21_05evt.c:93: error: for each function it appears in.)
AC_OM_NonWorking.gridTest21_05evt.c: In function 'AC_OM_NonWorking_gridTest21_function_updateRelations':
AC_OM_NonWorking.gridTest21_05evt.c:138: error: '$Ptrain' undeclared (first use in this function)
mingw32-make: * [AC_OM_NonWorking.gridTest21_05evt.o] Error 1
mingw32-make: * Waiting for unfinished jobs....
Compilation process exited with code 2

[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).

[Henning Kiel]

It looks like the for loop iterator $Pi is just appended in the variables' names.
Also a cast is added which makes the thing look like a function call.

If you change the model code to

  algorithm
    lostPower := 0;
    lostPower := lostPower + resisLeft[1].v * resisLeft[1].i;
    lostPower := lostPower + resisRight[1].v * resisRight[1].i;
    lostPower := lostPower + resisLeft[2].v * resisLeft[2].i;
    lostPower := lostPower + resisRight[2].v * resisRight[2].i;
    lostPower := lostPower + resisLeft[3].v * resisLeft[3].i;
    lostPower := lostPower + resisRight[3].v * resisRight[3].i;

then you see that the arrays have only length 2, because you get compilable code for *[1] and *[2], but not for *[3].

Something is rotten in the state of denmark...

[Henning Kiel]

The following code is generated for the array accesses:

    modelica_integer $Pi;
    for($Pi = (modelica_integer) 1; in_range_integer($Pi, tmp81, tmp83); $Pi += tmp82)
    {
      $PgridOneTrack$PlostPower = ($PgridOneTrack$PlostPower + ($PgridOneTrack$PresisLeft$lB(modelica_integer)$Pi$rB$Pv * $PgridOneTrack$PresisLeft$lB(modelica_integer)$Pi$rB$Pi));

      $PgridOneTrack$PlostPower = ($PgridOneTrack$PlostPower + ($PgridOneTrack$PresisRight$lB(modelica_integer)$Pi$rB$Pv * $PgridOneTrack$PresisRight$lB(modelica_integer)$Pi$rB$Pi));
    }

You see that array access is done by concatenating the iterating variable name in the array name, which should not work, because it is not a fixed number!

gridOneTrack.resisLeft[i].v -> $PgridOneTrack$PresisLeft$lB(modelica_integer)$Pi$rB$Pv

So, either the for loop must be unrolled in Compiler or CodegenC.tpl must create proper code, which I currently see no quick solution for.

[massimo ceraolo]

Something is rotten in the state of denmark...

ehm...
Shakespeare, Hamlet, act I scene 4...

[Lennart Ochel]

Seem to be similar to #3082.

[Mahder Alemseged Gebremedhin]

Okay the issue with the qualified name indexing has been fixed in r24578 (use r2481 or newer).

However now we have a different issue with how we handle zero crossings in cases like

algorithm section -> for loop -> for loop - some event triggering expression 

for example

  algorithm
    for train in 1:numOfTrains loop
      z[train] := 1;
      for sect in 1:numOfSect loop
        if trainPos[train] > iniSecPos[sect] then
          z[train] := z[train] + 1;
        end if;
      end for;
    end for;

It seems we only keep track of one iterator at a time. that means iterators from outer loops are not detected when analyzing expressions inside statements of the inner loop.

I will see if I can fix that.

However there is the basic structural issue we had with the array indexing here as well. Right now it seems zero crossings are detecting by expanding arrays that use the iterator. This requires knowing the range of the loop at compile time. What happens when you can not evaluate and determine that?

Lennart, Willi : any ideas?

[Mahder Alemseged Gebremedhin]

Oh btw I have removed some unnecessary ASUB creations in r24602. This affects what you used to generate for zero crossings. It used to be these long switch case statements one for each index. Now it is simple direct indexing. Keep the changes in mind if you use newer that r24602.

*the issue remains the same for both kinds of generations.

[Willi Braun]

Replying to mahge930:

Lennart, Willi : any ideas?

Yes, we handle algorithm sections wrong for zero-crossings, see also #2927 or #2997.

[massimo ceraolo]

I've made two more tests with r24918.
1) from the code in comment 13:

model Test
  parameter Integer numOfTrains = 2, numOfSect = 3;
  Integer z[numOfTrains];
  Real trainPos[numOfTrains] = {10, 20}, iniSecPos[numOfSect] = {5, 15, 25};
algorithm
  for train in 1:numOfTrains loop
    z[train] := 1;
    for sect in 1:numOfSect loop
      if trainPos[train] > iniSecPos[sect] then
        z[train] := z[train] + 1;
      end if;
    end for;
  end for;
end Test;

This compilates and runs.

2) A slightly modified version (more similar to my original example):

model TestAlgorithm
  parameter Integer numOfTrains = 2, numOfSect = 3;
  Integer z[numOfTrains] = {1, 2};
  Real trainPos[numOfTrains] = {10, 20}, iniSecPos[numOfSect] = {5, 15, 25};
  Integer trainInZ[numOfSect + 1];
algorithm
  for sect in 1:numOfSect + 1 loop
    trainInZ[sect] := 0;
    for train in 1:numOfTrains loop
      if z[train] == sect then
        trainInZ[sect] := train;
      end if;
    end for;
  end for;
end TestAlgorithm;

This generates the following error:

TestAlgorithm_05evt.c: In function 'TestAlgorithm_function_ZeroCrossings':
TestAlgorithm_05evt.c:80: error: '$Psect' undeclared (first use in this function)
TestAlgorithm_05evt.c:80: error: (Each undeclared identifier is reported only once
TestAlgorithm_05evt.c:80: error: for each function it appears in.)
TestAlgorithm_05evt.c: In function 'TestAlgorithm_function_updateRelations':
TestAlgorithm_05evt.c:101: error: '$Psect' undeclared (first use in this function)
mingw32-make: * [TestAlgorithm_05evt.o] Error 1
mingw32-make: * Waiting for unfinished jobs....
Compilation process failed. Exited with code 2.

Both models run with Dymola.

I must add that I expect that it's not necessary that events are triggered when my integer numbers change. But in this snippet I don't know where to put noEvent() operator.

[massimo ceraolo]

ok code 2 in my comment # 16 works if I use:

if noEvent(z[train] == sect) then

instead of

if z[train] == sect then

Since I did not need an event there, this solves my problem, at least.

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

[Martin Sjölund]

The testsuite had a bug marked #2756, which now works. The original model still does not work though.

[massimo ceraolo]

I checked the two examples in comment #16.
Three years ago 1) was ok, 2) had issues.
Not the situation is reversed: 1) shows errors, 2) compiles and runs.

Checked with v1.13.0-dev-47-g453670f (32-bit for Win)

[Martin Sjölund]

Both examples in comment:16 work for me. What error did you get for example 1? Your OMC isn't that old so I would expect the same result as I got...

[massimo ceraolo]

My compiler is rather new (see comment 25).
Here's the message I get:

E:/Programmi/OpenModelica//share/omc/scripts/Compile.bat Test gcc mingw32 parallel 8 0
PATH = "E:\programmi\OpenModelica\tools\msys\mingw32\bin;E:\programmi\OpenModelica\tools\msys\mingw32\bin\..\..\usr\bin;"
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test.o Test.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_functions.o Test_functions.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_records.o Test_records.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_01exo.o Test_01exo.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_02nls.o Test_02nls.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_03lsy.o Test_03lsy.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_04set.o Test_04set.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_05evt.o Test_05evt.c
gcc    -falign-functions -msse2 -mfpmath=sse      -I"E:/Programmi/OpenModelica//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=Test -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0  -c -o Test_06inz.o Test_06inz.c
Test_05evt.c: In function 'Test_function_ZeroCrossings':
Test_05evt.c:63:132: error: '$Ptrain' undeclared (first use in this function)
   tmp0 = GreaterZC((&data->localData[0]->realVars[3] /* trainPos[1] variable */)[calc_base_index_dims_subs(1, 2, (modelica_integer)$Ptrain)], data->localData[0]->realVars[0] /* iniSecPos[1] variable */, data->simulationInfo->storedRelations[0]);
                                                                                                                                    ^
Test_05evt.c:63:132: note: each undeclared identifier is reported only once for each function it appears in
Test_05evt.c: In function 'Test_function_updateRelations':
Test_05evt.c:90:134: error: '$Ptrain' undeclared (first use in this function)
     tmp3 = GreaterZC((&data->localData[0]->realVars[3] /* trainPos[1] variable */)[calc_base_index_dims_subs(1, 2, (modelica_integer)$Ptrain)], data->localData[0]->realVars[0] /* iniSecPos[1] variable */, data->simulationInfo->storedRelations[0]);
                                                                                                                                      ^
<builtin>: recipe for target 'Test_05evt.o' failed
\tools\msys\mingw32\bin\mingw32-make: *** [Test_05evt.o] Error 1
\tools\msys\mingw32\bin\mingw32-make: *** Waiting for unfinished jobs....
Compilation process failed. Exited with code 2.

[Martin Sjölund]

Do you have any specific debug-flags set? OMEdit and OMC work fine for me with the exact same hash (in Linux), and actually doesn't contain any zero-crossing...

[massimo ceraolo]

ok!

I removed all simulation flags, and now both models in comment 16 run successfully.
The original model still has issues also on my system.

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