Issue with MultiBody models in the NF due to lack of scalar product expansion

[Francesco Casella]

Please check ​Modelica.Mechanics.MultiBody.Examples.Elementary.LineForceWithTwoMasses. Some analysis carried out with the transformational debugger reveals that the equation

revolute1.tau = -revolute1.frame_b.t * revolute1.e;

coming out of the NF is firsts transformed by substitution into

revolute1.constantTorque.tau_constant = 
  -{-bodyBox1.frame_a.t[1], -bodyBox1.frame_a.t[2], -bodyBox1.frame_a.t[3]} * revolute1.e

which is correct, and then solved in the torn section of a nonlinear system as

bodyBox1.frame_a.t[2] =
  (-({-bodyBox1.frame_a.t[1], -0.0, -bodyBox1.frame_a.t[3]} * revolute1.e + revolute1.constantTorque.tau_constant)) / ({-0.0, -1.0, -0.0} * revolute1.e)

that would be OK if {0,-1,0}*e <> 0, which is unfortunately not the case here.

The old FE instead expands the scalar product in the equation, passing it to the back-end as

  revolute1.tau = (-revolute1.frame_b.t[3]) * revolute1.e[3] - revolute1.frame_b.t[1] * revolute1.e[1] - revolute1.frame_b.t[2] * revolute1.e[2];

which allows the back-end to process the equations correctly and eventually find the ​correct result. This issue currently prevents a lot of MultiBody models to simulate when using the NF.

I see two problems here. The first is that the NF does not expand revolute1.e into its components and subsequently compute the scalar product explicitly, as the OF did. If this could be fixed, we should hopefully get most of the MultiBody models to work with the NF.

The second is that the back-end solves an equation in a dubious way, which turns out to be singular. I'm not sure whether it is possible to avoid this behaviour without introducing unnecessary restrictions that could harm the successful symbolic solution of equations in other cases.

In any case, I guess it will be best to make sure that the NF expands the scalar product as the NF did.

[Francesco Casella]

BTW, it is too bad that the the Rotational MSL component contains the declaration

parameter Real e[3](each final unit="1")=
  Modelica.Math.Vectors.normalizeWithAssert(n);

instead of

final parameter Real e[3](each final unit="1")=
  Modelica.Math.Vectors.normalizeWithAssert(n);

which would allow to further simplify the equation since n has Evaluate = true and normally only has one non-zero component. I'll open a PR for MSL 3.2.3 on this topic.

[Francesco Casella]

In fact, the declaration of e is in the protected section, so e should be evaluated anyway, even if it is not final. See #5084.

[Per Östlund]

Fixed in b8a0777. The model now simulates correctly.