Archived issue #0023832
sprops and triarea commands return incorrect value of a mass for shape of revolution
Description
sprops and triarea commands return incorrect value of a mass for shape of revolution. Both of these commands use the BRepGProp::SurfaceProperties and the GProp_GProps for definition of mass of a given shape, but the result value is much greater that expected.
Exploding the result shapes on faces gives that incorrect value is calculated for initial face used for forming the whole shape.
At the same time the similar face closing the shape is processed correctly.
for test case bugs modalg_2 bug22818_1:
triarea result
# triangles - 671.7785430027094
# gemetrical - 823.38488345995472
explode result f
donly result_4 result_3
sprops result_4
# Mass : 50
sprops result_3
# Mass : 200
Exploding the result shapes on faces gives that incorrect value is calculated for initial face used for forming the whole shape.
At the same time the similar face closing the shape is processed correctly.
for test case bugs modalg_2 bug22818_1:
triarea result
# triangles - 671.7785430027094
# gemetrical - 823.38488345995472
explode result f
donly result_4 result_3
sprops result_4
# Mass : 50
sprops result_3
# Mass : 200
Steps to reproduce
bugs modalg_2 bug22818_1 bug22818_2
Public activity
5 archived notes
Participants are labeled by their role within this record.
Dear OAN,
the problem is not in sprops and triarea commands. In scripts bugs modalg_2 bug22818_1 bug22818_2 faces are created incorrectly:
mkface f1 pln
add w1 f1
should be:
mkface f1 pln w1
otherwise the value of mass calculate by non-relevant function.
the problem is not in sprops and triarea commands. In scripts bugs modalg_2 bug22818_1 bug22818_2 faces are created incorrectly:
mkface f1 pln
add w1 f1
should be:
mkface f1 pln w1
otherwise the value of mass calculate by non-relevant function.
Dear IKA,
I suppose that this way is possible for face creation, because:
- usage of mkface is described as "mkface facename surfacename [ufirst ulast vfirst vlast] [wire[norient]]
that means a wire is not an obligatory component;
- checkshape command doesn't indicate any problem;
- incmesh doesn't indicate any problem too and computes mesh correctly.
I suppose that this way is possible for face creation, because:
- usage of mkface is described as "mkface facename surfacename [ufirst ulast vfirst vlast] [wire[norient]]
that means a wire is not an obligatory component;
- checkshape command doesn't indicate any problem;
- incmesh doesn't indicate any problem too and computes mesh correctly.
Creation faces in scripts bugs modalg_2 bug22818_1 and bug22818_2 was changed to right way.
Branch CR23832 is ready to be reviewed.
Dear GKA,
Please review.
Branch CR23832 is ready to be reviewed.
Dear GKA,
Please review.
Branch CR23832 is ready to be tested
Dear Commenter 2,
Test cases
bugs modalg_2 bug22818_1 and bug22818_2
was corrected and tested in CR22818 branch.
Test cases are OK.
Test cases bugs modalg_2 bug22818_1 and bug22818_2 was pushed in git branches CR23832 and CR22818.
Branch CR23832 is TESTED.
Test cases
bugs modalg_2 bug22818_1 and bug22818_2
was corrected and tested in CR22818 branch.
Test cases are OK.
Test cases bugs modalg_2 bug22818_1 and bug22818_2 was pushed in git branches CR23832 and CR22818.
Branch CR23832 is TESTED.
Related records