id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5114	Issue with MultiBody models of ScalableTestSuite with the NF	Francesco Casella	Per Östlund	"The last remaining models of ScalableTestSuite which are not handled by the NF are the {{{FlexibleBeamModelica}}} and {{{StringModelica}}} models. The issue is quite intricate but I think I understood what happens. 

For example, you can check [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Mechanical.Strings.ScaledExperiments.StringModelica_N_2.err ScalableTestSuite.Mechanical.Strings.ScaledExperiments.StringModelica_N_2], which reports this error:
{{{
ScalableTestSuite_noopt_ScalableTestSuite.Mechanical.Strings.ScaledExperiments.StringModelica_N_2_06inz.c:4331:38:
error: use of undeclared identifier '$Pbodybox$lB1$rB$Pbody$PR_start$PT'
  copy_real_array_data_mem(tmp2._T, &$Pbodybox$lB1$rB$Pbody$PR_start$PT);
}}}

The issue is with the parameter-binding equation
{{{
  final parameter Frames.Orientation R_start=
      Modelica.Mechanics.MultiBody.Frames.axesRotations(
        sequence_start,
        angles_start,
        zeros(3));
}}}
of the Modelica.Mechanics.MultiBody.Parts.Body model, which is moved as a whole by the new front end into the initial equation section as 
{{{
  bodybox[1].body.R_start = Modelica.Mechanics.MultiBody.Frames.axesRotations(
  {1, 2, 3}, bodybox[1].body.angles_start, {0.0, 0.0, 0.0});
}}}

which the back-end cannot handle. The old-front end constant-evaluates the binding equation and expands it to its scalar components
{{{
  final parameter Real bodybox[1].body.R_start.T[1,1] = 1.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[1,2] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[1,3] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[2,1] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[2,2] = 1.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[2,3] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[3,1] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[3,2] = 0.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.T[3,3] = 1.0 ""Transformation matrix from world frame to local frame"";
  final parameter Real bodybox[1].body.R_start.w[1](quantity = ""AngularVelocity"", unit = ""rad/s"") = 0.0 ""Absolute angular velocity of local frame, resolved in local frame"";
  final parameter Real bodybox[1].body.R_start.w[2](quantity = ""AngularVelocity"", unit = ""rad/s"") = 0.0 ""Absolute angular velocity of local frame, resolved in local frame"";
  final parameter Real bodybox[1].body.R_start.w[3](quantity = ""AngularVelocity"", unit = ""rad/s"") = 0.0 ""Absolute angular velocity of local frame, resolved in local frame"";
}}}

which is trivial for the back-end to handle.

However, looking at the {{{axesRotation()}}} function call, the parameter {{{R_start}}} is final, {{{sequence_start}}} has {{{Evaluate = true}}} and {{{zeros(3)}}} is a literal constant, but {{{angles_start}}} doesn't have {{{Evaluate = true}}}, so I'm not sure why the old front-end constant-evaluates the right-hand-side of the binding equation. Maybe just the fact of being final was used to trigger that, though it needs not necessarily be the case: a final parameter may depend on another parameter that is not evaluated and that should be changeable at runtime. 

{{{axesRotation}}} has {{{Inline = true}}}, but I understand this is only relevant for the back-end, the front-end never inlines anything.

So, I don't think we should try to reproduce the old front-end behaviour here, because it performs an unnecessary evaluation. On the other hand, we need a viable solution to get ScalableTestSuite to run ASAP.

I checked [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/files/Modelica_trunk_Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum.err Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum], which runs fine with the NF, and produces the initial equation
{{{
  boxBody1.body.R_start = Modelica.Mechanics.MultiBody.Frames.axesRotations(
  {1, 2, 3}, boxBody1.body.angles_start, {0.0, 0.0, 0.0});
}}}
which is handled correctly. So, I understand there is some problem with code generation of
{{{
  bodybox[1].body.R_start = Modelica.Mechanics.MultiBody.Frames.axesRotations(
  {1, 2, 3}, bodybox[1].body.angles_start, {0.0, 0.0, 0.0});
}}}
because in the latter case the left-hand-side has some indexing, while the former case doesn't.

I'm not sure whether this is because the new front-end creates a somewhat invalid data structure in this case, or rather that the back-end or simcode should be amended by adding the case of array element on the left-hand-side, maybe that's just a trivial fix.

@perost, @lochel, @adrpo, @wbraun can you agree on a solution for this case?"	defect	closed	high	2.0.0	New Instantiation		fixed		Bernhard Bachmann Willi Braun Per Östlund