Problem with code generation involving arrays of components containing arrays of Real variables

[Francesco Casella]

Please consider the model DEMOSimple.Test.Helium.TestCP from the attached package. The model is accepted by the front-end, and it actually simulates successfully in Dymola.

However, when compiling the C code generating by OMC, the following error message pops up:

DEMOsimple.Test.Helium.TestCP_02nls.c: In function 'residualFunc53':
DEMOsimple.Test.Helium.TestCP_02nls.c:53:3: error: '$OLD_$PheliumCP$PchB$lB2$rB$PTm$lBtmp3$rB' undeclared (first use in this function)
   $OLD_$PheliumCP$PchB$lB2$rB$PTm$lBtmp3$rB = $PheliumCP$PchB$lB2$rB$PTm$lBtmp4$rB;
   ^

The involved variable is an element of a Real array inside an array of models.

Can you please have a look and fix it?

[Francesco Casella]

Test package

[Francesco Casella]

Tried it also with --simCodeTarget=Cpp.

On Windows, we get

OMCppDEMO.Test.Helium.TestCPAlgloop67.cpp: In member function 'virtual void TestCPAlgloop67::evaluate()':
OMCppDEMO.Test.Helium.TestCPAlgloop67.cpp:70:32: error: 'heliumCP_P_chB_P_Tm_' was not declared in this scope
       heliumCP_P_chB_P_Tm_(2,i_) = 573.15 /*stmtAssign*/;

which is similar to the issue with C code generation.

On Linux, we get this:

DEMO.Test.Helium.TestCP.makefile:3: /usr/include/omc/cpp/ModelicaConfig_gcc.inc: No such file or directory
DEMO.Test.Helium.TestCP.makefile:4: /usr/include/omc/cpp/ModelicaLibraryConfig_gcc.inc: No such file or directory
make: *** No rule to make target '/usr/include/omc/cpp/ModelicaLibraryConfig_gcc.inc'.  Stop.

[Antonio Froio <antonio.froio@…>]

It seems related to initialization: the start values for all the faulty variables are assigned within an initial algorithm section. In particular, within the model DEMOsimple.HeliumPipe:

• the variables are declared as SI.Temperature Tm[N]; (line 204);
• the initial values is assigned conditionally (lines 218-223), where Cm is a parameter and prop.Tnom is a constant:

  initial algorithm
    if Cm > 0 then
      for i in 1:N loop
        Tm[i] := prop.Tnom;
      end for;
    end if;
  

If the initial algorithm section is removed and the declaration is changed with SI.Temperature Tm[N](each start = prop.Tnom, each fixed = (Cm > 0)); the model simulates correctly.

In the given example, the parameter Cm was set to 1, which is > 0, so the initial value was to be set inside the initial algorithm section, but OMC incorrectly warned about those variables not having a fixed initial value, which is probably related to the reported issue. Anyway, the two versions have identical meaning and are both fully spec-compliant IMHO, so they should yield the same result.

[Mahder Alemseged Gebremedhin]

The involved variable is an element of a Real array inside an array of models.

Exactly the problem.

The problem here was the way we collected algorithm outputs. If there is an array access in an algorithm section then the whole array is considered as an output of the algorithm. To handle this we had a special way of counting.

The reason was that if the algorithm section comes from an array of a model then we already have multiple algorithm section in the flat model from each member model. In this case we should not consider the whole array as modified in each algorithm section section since this will lead to multiple counting.

When we have algorithm sections from arrays of models which themselves contains arrays used in their own section, we needed to be selective of which part of the array we count as whole. This is exactly what is happening in this model.

I have a fix here
​https://github.com/mahge/OMCompiler/commit/c76ae148c2ceb2c2617ed94a37b0eeef6831f679

However currently one test fails from the testsuite.
/testsuite/simulation/modelica/algorithms_functions/AlgorithmSize.mo

The test is failing because the module removeSimpleEquations replaces assigned variables of an algorithm section by some array members while aliasing variables. Subsequent optimizations or processing that tries to count the outputs of the algorithm will get a higher count since there is now an array member there and we consider the whole array as modified.

I will figure out how to work around that.

[Mahder Alemseged Gebremedhin]

Replying to Antonio Froio <antonio.froio@…>:

If the initial algorithm section is removed and the declaration is changed with SI.Temperature Tm[N](each start = prop.Tnom, each fixed = (Cm > 0)); the model simulates correctly.

This can be an easy workaround until the fix is resolved and merged.

[Francesco Casella]

Milestone changed to 1.13.0 since 1.12.0 was released

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed