sketcher: wrong redundancy solving with symmetry

[uwestoehr]

Interestingly, if I apply the Symmetry Constraint before the 4mm Horizontal Distance Constraint, there is no problem (one of the Conflicting Constraints probably got deleted).

Many thanks, this works! :

Sketch-symmetry-issue3.FCStd

this works

(9.88 KiB) Downloaded 17 times

So what I want is possible but it matters in which order you apply the constraints. I insist that this cannot be correct. So either it is mathematically over constrained or not. It cannot be that the same set of constraints lead to 2 different results. (I am no mathematician but this is weird for an engineer )

The question here isn't what you need. The solver don't care of that.

Sure but apparently the solver can do. I have no clue why the order matters.

[openBrain]

Sure but apparently the solver can do. I have no clue why the order matters.

It's a bug ! It works but it shouldn't !
Just delete the symmetry on your file and you see 1 DoF while deleting a symmetry should release 2 of them.

EDIT: this is exactly (IMO) the bug I described on this previous post.

[uwestoehr]

It's a bug ! It works but it shouldn't !

I like this bug .

Seriously, do you report the bug or do I?

[chrisb]

There is no need to report this bug, as we have discussed it before. It is one of these "silently drop a redundant constraint" issues.

[chrisb]

A correct way of constraining this is to apply a horizontal constraint instead of symmetry. With the center of the arc being on the Y-axis this mathematically implies symmetry.

[uwestoehr]

There is no need to report this bug, as we have discussed it before. It is one of these "silently drop a redundant constraint" issues.

I don't agree. The same set of constraints cannot result one time on an over-constraint one time not. This is not how a solver should work. Using the same input parameters it must find the same solution.

A crrect way of constraining this is to apply a horizontal constraint instead of symmetry. With the center of the arc being on the Y-axis this mathematically implies symmetry.

But I already explained twice in this thread why I need a symmetry constraint and not some other methods.
A symmetry is more or less 2 constraints in one and there are good reasons to use this and not a set of 2 other constraints.

[chrisb]

There is no need to report this bug, as we have discussed it before. It is one of these "silently drop a redundant constraint" issues.

I don't agree.

What is it you don't agree with. That we discussed this before? That a bug report is already filed?

But I already explained twice in this thread why I need a symmetry constraint and not some other methods.

Not true. You said it twice, but never explained it.

A symmetry is more or less 2 constraints in one and there are good reasons to use this and not a set of 2 other constraints.

The symmetry is implied if you use a horizontal constraint without redundancies. So it is mathematically there. These points are symmetric.
What you seem to want is to have an additional anticipatory constraint which you can use later when changing something in a carbon copied sketch. That's not how the solver works and not how it should work. In my view it is not sensible to overload a sketch with additional constraints just in case that another sketch may use a more or less reasonable subset of them.

[bejant]

I went back to the original file that uwestoehr posted, and started to recreate the Sketch (my recreation is Sketch001 in the attached file). Before applying the 4 mm Horizontal Distance Constraint between the upper left Endpoint and the Origin, and before applying a Symmetry Constraint between two Endpoints of one of the Arcs and the Vertical Axis, I applied the Equality Constraint to the two Line Segments. Sketcher reports one remaining DOF, and I agree:

20190716b.png (31.99 KiB) Viewed 753 times

Using the constraint style of the original Sketch, the missing Constraint is the 4 mm Horizontal Distance Constraint between the upper left Vertex and the Origin.

The centers of both Arcs are Constrained onto the origin, the Arcs are Constrained to have equal radii, and both the Line Segments are Constrained to be Vertical and to be Equal. This creates Symmetry about both the Vertical Axis and the Horizontal Axis, and I can animate that if I drag any Endpoint.

When I apply a Symmetry Constraint between the Endpoints of one Line Segment and the Horizontal Axis, the Solver correctly informs that I've created a Redundant Constraint. This happens for the other line segment too.

But, I can apply a Symmetry Constraint between both Endpoints of one Arc and the Vertical Axis, and the Solver doesn't recognize that I have just created a Redundant Constraint. I think a bug is that the Solver doesn't recognize the forced Symmetry that exists horizontally before that Symmetry Constraint is applied.

20190716a-Sketch-symmetry-issue.FCStd

(11.38 KiB) Downloaded 14 times

Same FC version as before.

[kisolre]

As I understood from another thread where Abdullah explained it the solver reports redundant constraints IF they can be removed and not add extra DOF. It tries to find such constraints and if fails it silently removes that redundancy from the constraint that caused it (for the symmetry the horizontal part probably).

[openBrain]

I like this bug .

I figured it out from the beginning of this thread.

Seriously, do you report the bug or do I?

I think the best at this point it to get the honor of abdullah's opinion. I'll ask for it in a subsequent post so he hasn't too much to read.

A correct way of constraining this is to apply a horizontal constraint instead of symmetry. With the center of the arc being on the Y-axis this mathematically implies symmetry.

You're looping back the discussion to its beginning.

There is no need to report this bug, as we have discussed it before. It is one of these "silently drop a redundant constraint" issues.

I don't agree.

What is it you don't agree with. That we discussed this before? That a bug report is already filed?

Sorry chrisb but I also agree we have to do something with this (except if this case is already known and documented). That's OK that the solver can't automatically remove redundant in that case (kisolre's explanation makes sense). But there is something weird that the solver doesn't detect and warn about the redundant constraining.