Missing replacement of identifiers when inlining functions

[Rüdiger Franke]

OpenModelica generated unnecessarily large and non-linear equation systems for the PowerSystems library so far. The reason was missing annotation(Inline=true) for small one-liner functions.

Commit
​https://github.com/modelica/PowerSystems/commit/61ba3296af8b2ebdcb86adff0c222291a6a820d7
introduces these annotations.

In some models the compilation fails due to missing identifier xx now. This comes from inlining PhaseSystems.ThreePhase_dq0.jj. See an example:

model InlineMatrixFunction
  function jj "Vectorized version of j"
    input Real[:,:] xx "array of voltage or current vectors";
    output Real[size(xx,1),size(xx,2)] yy "array of rotated vectors";
  algorithm
    yy := cat(1, {-xx[2,:], xx[1,:]}, zeros(size(xx,1)-2, size(xx,2)));
    annotation(Inline=true);
  end jj;
  Real[3, 1] v = {{1}, {2}, {3}};
  Real[3, 1] jv = jj(v);
end InlineMatrixFunction;

See e.g.:

PowerSystems.Examples.Spot.AC3ph.Line
PowerSystems.Examples.Spot.TransmissionAC3ph.FaultTline
PowerSystems.Examples.Spot.TransmissionAC3ph.Tline

Unfortunately the nightly tests don't report backenddaeinfo. Shouldn't the nightly tests use the same options for MSL and for other libraries, like PowerSystems?

[Vitalij Ruge]

possible connect to #3687 and cat

[Rüdiger Franke]

It does not seem to be cat. Where is the function inlined, in the frontend module referred in comment:1 or in the new backend module?

[Vitalij Ruge]

In the defaulte case the function is inliened from backend modul, which call the Frontend functions for expresion modification.
(Note: --inlineMethod=append and --inlineMethod=replace return different systems)

If we disable the backend module.

--preOptModules-=normalInlineFunction  +d=optdaedump --postOptModules-=lateInlineFunction > dump.log

then a other modul (possible: in index reduction inlineOrgEqns) will inline the function.
Disable inlining for evry modul with

+d=noinlineFunctions // INLINE_FUNCTIONS=False

help to start simulation.

[Vitalij Ruge]

The issues is in the function getExpFromArgMap.
This function call

subs := ComponentReference.crefSubs(inComponentRef);

and then the function call

 Expression.applyExpSubscripts(exp,subs);

which was failed for DAE.WHOLEDIM = [:].With
​skipped we skipped WHOLEDIM input. The example about seem to work. Anaway I'm not sure if skipped it a genrel solution. Adrain can you have a look?

By the way since ​inlineLoops we have a modul for force inlining of function in loops.

[Rüdiger Franke]

This looks good. Thank you!

Why did you assign the ticket to adrpo instead of closing it?

[Vitalij Ruge]

Replying to rfranke:

This looks good. Thank you!

Why did you assign the ticket to adrpo instead of closing it?

I am afraid we get possible some issues with some constructs like

yy := -xx[2,:,1,:,:,2]

Anyway it would be more safe to extend
function makeASUB for DAE.WHOLEDIM .
Aso using makeASUB in ​line956.

[Rüdiger Franke]

OK. Also the implementation of a regular program flow with try might be changed to some match case for WHOLEDIM. See ​skipped.

Anyway, good that inlining of the vectorized j operator works now.

[Vitalij Ruge]

possible test case:

loadString("

model foo
  function f
     input Real[:,:,:] x;
     output Real y;
  algorithm
     y := sum(x[:,:,1]);
     annotation(Inline=true);
  end f;
  constant Integer N = 5;
  Real x;
  Real y;
  Real [N, N, N] p;
equation
 for i in 1:5 loop
   for j in 1:5 loop
     for k in 1:5 loop
        p[i,j,k] = (if k == 1 then 1 else 0);
     end for;
   end for;
 end for;
 x = f(p);
 y = sum(p[:,:,1]);
end foo;

");
getErrorString();

simulate(foo);
getErrorString();

val(x, {0,1});
val(y, {0,1});

Note x should be equal y
with Inline=true and Inline=false we genreate diffrent values for x

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

[Francesco Casella]

Replying to rfranke:

In some models the compilation fails due to missing identifier xx now. This comes from inlining PhaseSystems.ThreePhase_dq0.jj. See an example:
See e.g.:

PowerSystems.Examples.Spot.AC3ph.Line
PowerSystems.Examples.Spot.TransmissionAC3ph.FaultTline
PowerSystems.Examples.Spot.TransmissionAC3ph.Tline

Using -d=newInst:

• ​PowerSystems.Examples.AC3ph.Elementary.Line works fine
• ​PowerSystems.Examples.AC3ph.Elementary.Fault works fine
• ​PowerSystems.Examples.AC3ph.Generation.TieLine fails because of #5243