sketcher: wrong redundancy solving with symmetry

[uwestoehr]

A special version of symmetry constraint formulation for this particular sketch will probably make no sense in other situations.
In this example, you can use horizontal constraint between these two points to properly constrain your sketch.

I wonder about the workarounds I got. What I post here are examples demonstrating a particular problem. Here I originally wanted to demonstrate a problem with symmetries.

Concerning symmetries I want them for good reasons and don't see why should not do this: In my construction the 2 points I constrained symmetric to the y-axis will always be symmetric, no matter what I later will must or might do with the sketch, the CC of the sketch etch. The symmetry constraint means same distance from axis in same height and this is exactly what these 2 points should have. It is confusing for me that I should use other methods, depending on the state of the sketch. My understanding is that FC offers the symmetry constraint and then it should work as documented.

[DeepSOIC]

The symmetry constraint means same distance from axis in same height and this is exactly what these 2 points should have. It is confusing for me that I should use other methods, depending on the state of the sketch. My understanding is that FC offers the symmetry constraint and then it should work as documented.

These two conditions are essentially two underlying constraints that are applied under the hood to realize the symmetry. In your sketch, applying the first part automatically fulfills the second. So applying the second, you get redundancy. So you're asking for freecad to just deal with redundancies, and solve the sketch anyway. FreeCAD wouldn't even complain about redundant constraints if they didn't cause trouble with solving. But as of now, they do, unfortunately, and fixing it is challenging.

[uwestoehr]

These two conditions are essentially two underlying constraints that are applied under the hood to realize the symmetry.

Ah, now I get it and understand what the problem is. I thought the symmetry constraint was a constraint of its own and not set in 2 steps but as one step. Maybe this could improve the situation: Apply distance and height internally but assure that the solver is first run after the second step.

[abdullah]

I think it (not ignoring partial redundancies) is not practical for the average user, but I will consider an orthodox mode for diehard DoF lover power users

The thing with the order of the constraints giving different solver results is IMO a bug and should be investigated further.

[abdullah]

These two conditions are essentially two underlying constraints that are applied under the hood to realize the symmetry.

Ah, now I get it and understand what the problem is. I thought the symmetry constraint was a constraint of its own and not set in 2 steps but as one step. Maybe this could improve the situation: Apply distance and height internally but assure that the solver is first run after the second step.

It is not a "two step" process in the sense that it is solved for one and then for the other. The basics are:

1. A sketcher constraint is implemented via one or more solver constraints, each solver constraint removing exactly one DoF.
2. Solver constraints seek convergence by calculating the gradient and minimizing the error.

Nevertheless, this is the issue with the partial redundancy. Not with differing result. Differing result is unacceptable.

[chrisb]

I think it (not ignoring partial redundancies) is not practical for the average user, but I will consider an orthodox mode for diehard DoF lover power users

For me a more or less generic solver message would be sufficient, perhaps showing in yellow to indicate a warning and not an error.
Going this way of comfort it may be considered to allow all redundant constraints. Though you may guess that this is not the behaviour I would appreciate.

[abdullah]

I think it (not ignoring partial redundancies) is not practical for the average user, but I will consider an orthodox mode for diehard DoF lover power users

For me a more or less generic solver message would be sufficient, perhaps showing in yellow to indicate a warning and not an error.
Going this way of comfort it may be considered to allow all redundant constraints. Though you may guess that this is not the behaviour I would appreciate.

Accumulation of redundant constraints leads to problems in the detection of redundant conflicting constraints. Such a comfort mode is not currently viable. In absence of a break-through, the strategy is to protect the solver against redundancies, so that the information provided by it is accurate (most of the time, ideally always).

I think that user expectations vary as the level of proficiency increases. An average user wants to just use the software. He may appreciate that with a deeper knowledge, he may be able to sketch faster, with higher robustness, lesser errors and out of occasional trouble. However, he may not be ready to want to learn what it takes to arrive there. Your level of user already has this knowledge, so you just ask to be notified in case that a distraction lead to a partially redundant constraint. I think you do make a lot of sense as far as notification goes. There is a bridge to cross from average user to expert. I think improved notification has special educational value for those who want to cross that bridge.

I do have some issues regarding which information to present to the user and whether the amount of information should be controlled by enabling an advanced mode (scaring mode for beginers).

What I am not sure is how an expert would deal with an orthodox mode in which partial redundants are not only notified, but enforced as errors. But I am ready for the experiment and I know you are ready for the challenge. Let me get a laptop

[openBrain]

I think it (not ignoring partial redundancies) is not practical for the average user, but I will consider an orthodox mode for diehard DoF lover power users

IMO, redundant constraints should always (at least) trigger a warning.
BTW, do you want this case here to be stored somewhere for testing or something else (or nothing) ? (Sorry if you already replied to this but I didn't see ).

Nevertheless, this is the issue with the partial redundancy. Not with differing result. Differing result is unacceptable.

Do you have a clue about where these differing results come from ? Is that linked to solver strategy that determines if a constraint is redundant ?