Sketcher Triangle Constraint issue

[garya]

I've come across a situation where Sketcher claims a triangle is fully constrained when it is not.
This may be related to issue #0000754
As nearly as I can tell, this is an unreported bug. Can anyone confirm?

The attached sketch is reported as having 1 degree of freedom left.
If you constrain the distance from
the center of the triangle to the Y-axis,
or
the point on the X axis to the Y-axis
Then the sketch is considered fully constrained.
It is not; you can flip it parallel to the Y-axis about the point used in the constraint and still meet the constraints.

If you attempt to set the distance from the side parallel to the Y-axis to the origin to a negative value, you get an error, "Negative datum values are not valid for the constraint with index 10". The constraint should be legal (it is legal/permitted to set a horizontal distance constraint negative), but it will suffer from the same problem as the other two.

[chrisb]

Please add for such issues always your FreeCAD info as advised following the IMPORTANT link above. I guess you use 0.17 and you should upgrade to 0.18 or 0.19.

A fully constrained Sketch does not mean that it is unique. It means only that there is no smooth transition to a different solution.

[NormandC]

It is not; you can flip it parallel to the Y-axis about the point used in the constraint and still meet the constraints.

I simply cannot figure out how to flip it after it's fully constrained. Can you explain how to do that?

For me, it works as expected - meaning, when the sketch is fully constrained, it's impossible to move any geometry.

OS: Ubuntu 18.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.1.
Build type: Release
Python version: 3.6.7
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/Canada (fr_CA)

(Unfortunately, the current freecad-stable Ubuntu package does not provide the revision number nor the hash; but it is indeed built from the 0.18.1 tag)

[chrisb]

The example is nevertheless interesting: I can add a coincidence constraint between the rightmost point of the rectangle and the origin. Before applying the skecth has 1 DOF, the coincidence consumes 2, so the sketch should be overconstrained. Alas it is not.

ping

[garya]

A fully constrained Sketch does not mean that it is unique. It means only that there is no smooth transition to a different solution.

I wasn't aware that a fully constrained sketch was not required to be unique.
I got to this simple case from an under-constrained condition in which adding the last constraint resulted in a fully constrained sketch that could not be solved ("Unsolved" shows up in red under "Fully constrained sketch" in the Task tab). As nearly as I can tell, the reason it cannot be "solved" is that it has more than one position that satisfies all the constraints. The extra solution is the one where it is flipped.

It is not; you can flip it parallel to the Y-axis about the point used in the constraint and still meet the constraints.

I simply cannot figure out how to flip it after it's fully constrained. Can you explain how to do that?

For me, it works as expected - meaning, when the sketch is fully constrained, it's impossible to move any geometry.

I cannot flip it by manipulating it. But the constraints allow for another positioning. I am assuming that is how the above "unsolved" problem comes about.

I have attached another file, the original source of the issue.
With the file Bug_Sketcher_ConstrainTriangle_2.FCStd:

Edit Sketch003 and try the following:
Select origin
Select vertical edge of triangle
Try to set length constraint (<->) to -8
You get an error saying the constraint can't be negative
Then select the same point and line and
Try to set the length constraint to "-Dim.Base_OD/2"
It will succeed but be "unsolved"

OS: UNIX
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.dace2f39cf
Build type: Release
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 7.3.0
Locale: C/Default (C)

[chrisb]

"Unsolved" means that your constraints are contradictory. "Redundant" means that one of the constraints can be derived from the others.

[garya]

"Unsolved" means that your constraints are contradictory. "Redundant" means that one of the constraints can be derived from the others.

Really?
At other times I've had it tell me constraints were contradictory:
"Cannot set the datum because the sketch contains conflicting constraints."
"Sketch contains conflicting constraints (click to select) Please remove at least one of the following constraints: ..."

I'm having trouble seeing a conflicting constraint; but it wouldn't be the first time I missed something.
From the original, unconstrained regular triangle, I added three constraints:
1. Length of one edge (and therefore all edges)
2. Make the leftmost edge parallel to the vertical axis
3. Make the rightmost vertex coincident with the horizontal axis
It's unclear to me how adding a constraint specifying how far the leftmost edge is from the origin conflicts with anything else. After the above three operations the triangle can be freely moved along the horizontal axis.

Whoa! The error is the result of the offset being negative, from a value in a spreadsheet. If you set it to a simple positive number, it works. If you try to set it to a simple negative number, it fails claiming you can't use a negative number [which I claim is a bug, since it is a distance in this case, not a line length]. If you set it to a negative number from a spreadsheet, it succeeds but with the unsolved error. If instead of the distance (<->) constraint you use the horizontal length (|-|) constraint to set the distance from a midpoint on the vertical line to some reference point it works, whether the distance number is positive or negative (negative numbers offset in the other direction)

[chrisb]

Lengths cannot be negative, distances can.
You should prefer horizontal distance constraint over length, if it is in fact horizontal. The same with vertical. Similar can be said about parallel: use vertical constraint instead of parallel to the Y-axis.

Please read about sketching in my tutorial https://owncloud.gwdg.de/index.php/s/HS ... I/download and ask back if you still have questions. All this is covered in decent depth.

[abdullah]

The example is nevertheless interesting: I can add a coincidence constraint between the rightmost point of the rectangle and the origin. Before applying the skecth has 1 DOF, the coincidence consumes 2, so the sketch should be overconstrained. Alas it is not.

ping

This is another example of a partially redundant constraint.

Sketcherwise a constraint is redundant when the constraint may be removed and arrive to the same DoF.

A sketcher coincident constraint removes 2 DoF. A solver constraint removes 1 DoF. The Sketcher Coincident constraint is implemented as 2 solver constraints.

What can be done does not depend only on the constraint added, but also the preexisting constraints. Let me try to illustrate it with an example. The starting point of the DoF is the same as in this example (only one DoF is missing).

Case A (this case):
I add the coincidence constraint and no other constraint may be removed fully, i.e. there is no other constraint that "removes" just 1 DoF, which is redundant with the coincidence constraint.

You are right to observe that a part of the coincident constraint is redundant with other constraints. However, there is no solution from a point of view of the Sketcher with the Sketcher constraints you are using.

There would be two possible ways of working for the solver here:
a) Annoy the user telling him that it does not like the coincidence constraint and asking the user to find another solution. We could provide some list of usual changes. For example, instead of a coincidence constraint, you could have put a horizontal alignment constraint.

b) Transparently remove the redundant part of the coincidence constraint while solving. This is what the solver currently does. It tells you here:

Code: Select all

EigenSparseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-13, Params: 17, Constr: 18, Rank: 17
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, dogLegGaussStep: FullPivLU, xsize: 17, csize: 17, maxIter: 100
DL: stopcode: 1, Success
Sketcher::RedundantSolving-DogLeg-
[b]Sketcher Redundant solving: 1 redundants[/b]
Sketcher::setUpSketch()-T:0

It goes like: hey there! I have got a rank 17 system with 18 solver constraints. I have made my math and I know I can safely remove one of this solver redundant constraints, because without it the solution converges, so I am doing it transparently just for you. I do this because I know you cannot remove that solver redundant constraint without affecting other solver constraints that are not redundant by removing sketcher constraints.

So far, in my experience, this (b) is a good solution. If there are corner cases, we could consider to convey this information to the solver messages dialog (solved with partially redundant constraints or something less technical). The thing is that there may be something to be done, like in this case "change coincidence with vertical alignment", but it is not obvious for a user and the solver cannot easily help here, at least as far as the current implementation goes (we could detect that the redundant is a solver horiz part of a coincidence and generate some custom message... maybe). Sometimes there may be no solution with alternative sketcher constraints.

Case B:
I add the coincidence constraint and another constraint may be removed fully, i.e. there is another sketcher constraint that "removes" just 1 DoF, which is redundant with the coincidence constraint. In this case, this sketcher constraint will me marked as redundant and removed either by the user or by the autoremove mechanism.

Bear with me for an example with this sketch.

Screenshot_20190414_095631.png (44.93 KiB) Viewed 1760 times

Do the following modifications to it.
a) Disable redundant autoremoval.
b) Add a horizontal alignment and a vertical alignment constraints between those points (i.e. implement a coincidence constraint with a vertical and a horizontal alignment constraints). The sketcher will complain about redundant, just ignore it.
c) delete the symmetry constraint.
At this point you are missing 1 DoF.
e) Readd the symmetry constraint.
At this moment you have one redundant constraint, the horizontal alignment one. But the solver knows you as a user can get rid of it because it is a fully redundant sketcher constraint. So it invites you to remove it (if you had the automatic removal option on, it would have been automatically removed).
f) Remove the redundant constraint
Now you have a fully constrained sketch with no partially redundant sketcher constraint:

Code: Select all

EigenSparseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-13, Params: 17, Constr: 17, Rank: 17
Sketcher::setUpSketch()-T:0
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, dogLegGaussStep: FullPivLU, xsize: 11, csize: 11, maxIter: 100
DL: stopcode: 1, Success
Sketcher::Solve()-DogLeg-T:0

Hope it makes sense...

[chrisb]

It makes perfectly sense, and I see that by internally removing the constraint no further issues in later steps are to be expected. However, I don't like to have constraints in my sketch that are used only partially, so I would like to have some kind of strict mode, where I simply get a message like "Parts of this constraint are redundant - remove redundant part.". This may lead to further musing about the sketch which may in the end lead to better constraints. E.g. in the case of the triangle I could get it with one vertical and several coincident constraints, even the circle could be deleted, which in the end is clearer (to me).