Opened 10 years ago

Last modified 7 years ago

#2756 accepted defect

OM reports an error in the C code it creates

Reported by: ceraolo Owned by: mahge930
Priority: high Milestone: Future
Component: Code Generation Version: trunk
Keywords: Cc: lochel, wbraun

Description (last modified by 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.

Attachments (3)

AutoCreateBug.mo (13.7 KB) - added by ceraolo 10 years ago.
AC_OM_Working.mo (13.6 KB) - added by ceraolo 10 years ago.
AC_OM_NonWorking.mo (13.7 KB) - added by ceraolo 10 years ago.

Download all attachments as: .zip

Change History (33)

Changed 10 years ago by ceraolo

comment:1 Changed 10 years ago by ceraolo

  • Description modified (diff)

comment:2 Changed 10 years ago by sjoelund.se

  • Component changed from Unknown to Code Generation
  • Owner changed from somebody to lochel

comment:3 Changed 10 years ago by lochel

  • Status changed from new to accepted

comment:4 Changed 10 years ago by lochel

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;

comment:5 Changed 10 years ago by mahge930

  • Owner changed from lochel to mahge930
  • Status changed from accepted to assigned

comment:6 Changed 10 years ago by mahge930

  • Status changed from assigned to accepted

comment:7 Changed 10 years ago by 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

Changed 10 years ago by ceraolo

Changed 10 years ago by ceraolo

comment:8 Changed 10 years ago by sjoelund.se

  • Milestone changed from 1.9.1 to 1.9.2

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

comment:9 follow-up: Changed 10 years ago by hkiel

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

comment:10 Changed 10 years ago by hkiel

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.

comment:11 in reply to: ↑ 9 Changed 10 years ago by ceraolo

Something is rotten in the state of denmark...

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

comment:12 Changed 10 years ago by lochel

Seem to be similar to #3082.

comment:13 follow-up: Changed 10 years ago by mahge930

  • Cc lochel wbraun added

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?

comment:14 Changed 10 years ago by mahge930

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 revisions newer than r24602.

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

Last edited 10 years ago by mahge930 (previous) (diff)

comment:15 in reply to: ↑ 13 Changed 10 years ago by wbraun

Replying to mahge930:

Lennart, Willi : any ideas?

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

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by sjoelund.se

  • Milestone changed from 1.9.2 to 1.9.3

Milestone changed to 1.9.3 since 1.9.2 was released.

comment:19 Changed 9 years ago by sjoelund.se

  • Milestone changed from 1.9.3 to 1.9.4

Moved to new milestone 1.9.4

comment:20 Changed 9 years ago by sjoelund.se

  • Milestone changed from 1.9.4 to 1.9.5

Milestone pushed to 1.9.5

comment:21 Changed 9 years ago by sjoelund.se

  • Milestone changed from 1.9.5 to 1.10.0

Milestone renamed

comment:22 Changed 8 years ago by sjoelund.se

  • Milestone changed from 1.10.0 to 1.11.0

Ticket retargeted after milestone closed

comment:23 Changed 8 years ago by sjoelund.se

  • Milestone changed from 1.11.0 to 1.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:24 Changed 7 years ago by sjoelund.se

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

comment:25 Changed 7 years ago by 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)

comment:26 Changed 7 years ago by sjoelund.se

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

comment:27 Changed 7 years ago by 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.

comment:28 Changed 7 years ago by sjoelund.se

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

comment:29 Changed 7 years ago by 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.

comment:30 Changed 7 years ago by casella

  • Milestone changed from 1.12.0 to Future

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.

Note: See TracTickets for help on using tickets.