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:2 by , 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.
follow-up: 6 comment:3 by , 6 years ago
Cc: | added |
---|
I understand fixing this issue would also get the PlanarMechanics library to work with the new front-end
comment:4 by , 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 , 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
comment:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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).
As far as I can tell there is a problem either with matrix creation or array construction:
This model:
Is flatten by NF to:
and by the current front-end to: