Opened 6 years ago

Closed 6 years ago

#5055 closed defect (fixed)

Issue with MultiBody models in the NF

Reported by: Francesco Casella Owned by: Per Östlund
Priority: high Milestone: 2.0.0
Component: New Instantiation Version:
Keywords: Cc: dirk.zimmer@…

Description

After @adrpo's commits for overconstrained connectors, the MultiBody examples all flatten and produce a balanced system of equations. However, there are still problems that prevents them to run.

Please check Modelica.Mechanics.MultiBody.Examples.Constraints.PrismaticConstraint. The following error is reported:

Modelica_trunk_Modelica.Mechanics.MultiBody.Examples.Constraints.PrismaticConstraint.c:146:58:
error: operand of type 'real_array' (aka 'struct base_array_s') where arithmetic or pointer type is required
  array_alloc_scalar_real_array(&tmp4, 2, (modelica_real)tmp5, (modelica_real)0.0);

Change History (6)

comment:1 by Adrian Pop, 6 years ago

As far as I can tell there is a problem either with matrix creation or array construction:
This model:

function resolve1  "Transform vector from frame 2 to frame 1" 
  input Real[3, 3] T "Orientation object to rotate frame 1 into frame 2";
  input Real[3] v2 "Vector in frame 2";
  output Real[3] v1 "Vector in frame 1";
algorithm
  v1 := transpose(T) * v2;
end resolve1;

model V
 Real R_rel[3,3];
 Real[2, 2, 2] lines "List of start and end points of cylinders resolved in an x-y frame defined by n_x, n_y, e.g., {[0,0;1,1], [0,1;1,0], [2,0; 3,1]}";
 parameter Integer n = size(lines, 1) "Number of cylinders";
 Real lengthDirection[n, 3] = {resolve1(R_rel, vector([lines[i, 2, :] - lines[i, 1, :]; 0])) for i in 1:n};
end V;

Is flatten by NF to:

  lengthDirection = array(resolve1(R_rel, vector({{{{lines[i,2,1], lines[i,2,2]}} - {{lines[i,1,1], lines[i,1,2]}}}, {0.0}})) for i in 1:2);

and by the current front-end to:

  lengthDirection = {resolve1({{R_rel[1,1], R_rel[1,2], R_rel[1,3]}, {R_rel[2,1], R_rel[2,2], R_rel[2,3]}, {R_rel[3,1], R_rel[3,2], R_rel[3,3]}}, {lines[1,2,1] - lines[1,1,1], lines[1,2,2] - lines[1,1,2], 0.0}), resolve1({{R_rel[1,1], R_rel[1,2], R_rel[1,3]}, {R_rel[2,1], R_rel[2,2], R_rel[2,3]}, {R_rel[3,1], R_rel[3,2], R_rel[3,3]}}, {lines[2,2,1] - lines[2,1,1], lines[2,2,2] - lines[2,1,2], 0.0})};
Last edited 6 years ago by Adrian Pop (previous) (diff)

comment:2 by Francesco Casella, 6 years ago

In fact, when comparing the model flattened with OF and NF, I see two different problems.

First, the OF returns this equation

sensorConstraintRelative.arrow.arrowLine.lengthDirection = 
{Modelica.SIunits.Conversions.to_unit1(sensorConstraintRelative.arrow.r_head[1]),   
 Modelica.SIunits.Conversions.to_unit1(sensorConstraintRelative.arrow.r_head[2]),  
 Modelica.SIunits.Conversions.to_unit1(sensorConstraintRelative.arrow.r_head[3])};

while the NF returns

sensorConstraintRelative.arrow.arrowLine.lengthDirection = 
 array(Modelica.SI.Cv.to_unit1(sensorConstraintRelative.arrow.r_head[$i1]) for $i1 in 1:3);

I guess reductions should be handled by the NF and not passed to the back-end.

Second, the OF returns

world.x_label.cylinders[1].lengthDirection = 
Modelica.Mechanics.MultiBody.Frames.TransformationMatrices.resolve1(
{{world.x_label.R_rel[1,1], world.x_label.R_rel[1,2], world.x_label.R_rel[1,3]}, 
 {world.x_label.R_rel[2,1], world.x_label.R_rel[2,2], world.x_label.R_rel[2,3]}, 
 {world.x_label.R_rel[3,1], world.x_label.R_rel[3,2], world.x_label.R_rel[3,3]}}, 
{world.x_label.lines[1,2,1] - world.x_label.lines[1,1,1], 
 world.x_label.lines[1,2,2] - world.x_label.lines[1,1,2],
 0.0});

while the NF returns

world.x_label.cylinders[1].lengthDirection = 
Modelica.Mechanics.MultiBody.Frames.T.resolve1(
world.x_label.R_rel, 
vector({
        {{{world.x_label.lines[1,2,1], world.x_label.lines[1,2,2]}} -  
         {{world.x_label.lines[1,1,1], world.x_label.lines[1,1,2]}}},
        {0.0}}));

The back-end can inline the output of the OF all the way down to

7/7 (1): world.x_label.cylinders[1].lengthDirection[3] = world.scaledLabel * (world.x_label.R_lines[1,3] + world.x_label.R_lines[2,3])   [dynamic |0|0|0|0|] 
8/8 (1): world.x_label.cylinders[1].lengthDirection[2] = world.scaledLabel * (world.x_label.R_lines[1,2] + world.x_label.R_lines[2,2])   [dynamic |0|0|0|0|] 
9/9 (1): world.x_label.cylinders[1].lengthDirection[1] = world.scaledLabel * (world.x_label.R_lines[1,1] + world.x_label.R_lines[2,1])   [dynamic |0|0|0|0|] 

while the output of the NF only gets to

2/10 (3): world.x_label.cylinders[1].lengthDirection = {{world.x_label.R_lines[1,1], world.x_label.R_lines[2,1], world.x_label.R_lines[3,1]}, {world.x_label.R_lines[1,2], world.x_label.R_lines[2,2], world.x_label.R_lines[3,2]}, {world.x_label.R_lines[1,3], world.x_label.R_lines[2,3], world.x_label.R_lines[3,3]}} * {{{world.scaledLabel, world.scaledLabel}}, 0.0}   [dynamic |0|0|0|0|] 

for which there are no rules to generate correct code. From the patterns I see, I suspect the culprit is the unexpanded vector() operator returned by the NF, though I'm not 100% sure.

comment:3 by Francesco Casella, 6 years ago

Cc: dirk.zimmer@… added

I understand fixing this issue would also get the PlanarMechanics library to work with the new front-end

comment:4 by Adrian Pop, 6 years ago

I think is also a problem on how the expression simplification of the old front-end is simplifying the expression after the NF generates the DAE. It it sees a vector expression, it looks for a matrix expression in it, but the NF *never* generates matrices, just arrays of arrays. Because of this the simplification is wrongly handled and the codegen fails because is normal to fail. Hopefully Per can sort this out quickly when he's back from holidays next week.

comment:5 by Adrian Pop, 6 years ago

The matrix: [lines[i, 2, :] - lines[i, 1, :]; 0] is evaluated badly by the NF:

The OF:

 {
   {lines[i,2,1] - lines[i,1,1]}, 
   {lines[i,2,2] - lines[i,1,2]}, 
   {0.0}
 }

The NF:

 {
   {{{lines[i,2,1], lines[i,2,2]}} - {{lines[i,1,1], lines[i,1,2]}}}, 
   {0.0}
 }

I guess in NF one of these are wrong in this particular case:

  • the array concatenation along the first dimension
  • the matrix subtraction
  • the array slice

in reply to:  3 comment:6 by Per Östlund, 6 years ago

Resolution: fixed
Status: newclosed

Fixed in a241b419.

Replying to casella:

I understand fixing this issue would also get the PlanarMechanics library to work with the new front-end

Indeed, all of PlanarMechanics now simulate except for one model that's invalid due to missing each (already reported here).

Note: See TracTickets for help on using tickets.