Large differences in back-end and simcode time with FluidDissipation test cases

[Francesco Casella]

Very similar test models using the Modelica.Fluid.Dissipation library take back-end times which are orders of magnitude different.

Consider, e.g., ​https://test.openmodelica.org/libraries/history/ModelicaTest_trunk-2016-03-21.html

ModelicaTest.Fluid.Dissipation.TestCases.PressureLoss.Bend: 253s
ModelicaTest.Fluid.Dissipation.TestCases.PressureLoss.Orifice: 0.13s

ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.Channel.kc_evenGapLaminar: 0.06s
ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.Channel.kc_evenGapLaminar_KC: 1.75s

ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.HelicalPipe.kc_turbulent: 0.063s
ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.HelicalPipe.kc_turbulent_KC: 8s

SimCode times also vary similarly.

I suspect analytical Jacobians might be involved. In any case, it seems that the *_KC tests are really taking too much time.

[Rüdiger Franke]

These examples basically consist of functions. Problems seem to arise whenever the backend attempts to simplify or inline those.

See also the discussion under 473cb9c/OMCompiler.

[Vitalij Ruge]

I guess the root is #3510 losing of temp-variables inside current inlining of function calls(recursive inlining of funtcion of function of function --> large large number of expression --> working on expression level like simplify or derivation can be only became slow)

[Vitalij Ruge]

e.g. inlinig of

IN_mflow.m_flow_in = Modelica.Fluid.Dissipation.PressureLoss.Bend.dp_edgedOverall_MFLOW(Modelica.Fluid.Dissipation.PressureLoss.Bend.dp_edgedOverall_IN_con(from_mflow.geometry.d_hyd, from_mflow.geometry.delta, from_mflow.geometry.K), Modelica.Fluid.Dissipation.PressureLoss.Bend.dp_edgedOverall_IN_var(Modelica.Fluid.Utilities.regStep(from_mflow.dp, 0.001, 0.001, 0.01923595898016073), Modelica.Fluid.Utilities.regStep(from_mflow.dp, 995.586, 995.586, 0.01923595898016073)), from_mflow.dp) 

[Francesco Casella]

Modelica.Fluid.Dissipation.PressureLoss.Bend.dp_edgedOverall_MFLOW has annotation(Inline = false). Why should it be inlined at all?

[Vitalij Ruge]

we have sometimes force inling #3531 e.g. for

• try to invert function
• analyse for index reduction
• ...

[Rüdiger Franke]

Shouldn't the modeler know better and the tool accept a directive Inline=false?

[Vitalij Ruge]

good idea with Inline=false...
Currently we don't have Inline=false. Inline=false is equal default NO_INLINE.

public uniontype InlineType
  record NORM_INLINE "Normal inline, inline as soon as possible"
  end NORM_INLINE;

  record BUILTIN_EARLY_INLINE "Inline even if inlining is globally disabled by flags."
  end BUILTIN_EARLY_INLINE;

  record EARLY_INLINE "Inline even earlier than NORM_INLINE. This will display the inlined code in the flattened model and also works for functions calling other functions that should be inlined."
  end EARLY_INLINE;

  record NO_INLINE "Avoid inline, this is default behaviour but is also possible to set with Inline=false"
  end NO_INLINE;

  record AFTER_INDEX_RED_INLINE "Try to inline after index reduction"
  end AFTER_INDEX_RED_INLINE;
end InlineType;

[Francesco Casella]

Replying to rfranke:

Shouldn't the modeler know better and the tool accept a directive Inline=false?

I fully endorse Ruediger's statement. If the modeller adds such directive, he/she has good reasons to do it, and expects the tool to compy, unless there are good reasons not to do so. I reckon Dymola initially tried to inline these functions and took forever to do that, so that eventually the developers of the Fluid.Dissipation library added that annotation to improve the situation.

Please make sure annotation(Inline=false) is actually used to disable inlining.

[Vitalij Ruge]

I will than open new ticket for support annotation(Inline=false).

[Vitalij Ruge]

Your(s) idea with guarding annotation(Inline=false) was introduced in #3791.

e.g. new time of ModelicaTest.Fluid.Dissipation.TestCases.PressureLoss.SeveralTestCases is interesting.
compare
​26.03
​25.03

[Francesco Casella]

Seems like this is now a solved problem.

[Martin Sjölund]

Milestone deleted