[PR] Sketcher Solver Improvements

[abdullah]

Similar situation with perpendiculars at an arc:
Bildschirmfoto 2018-04-28 um 00.25.38.png
If I connect the loose end of the radius to the center it shows erroneously 2 DOFs while it are in fact three.Bildschirmfoto 2018-04-28 um 00.28.04.png

I have managed to change on the fly from 3 to 4 DoFs just by dragging a point. I really think this goes in the direction of J formation.

[abdullah]

... To be solved as soon as merged to master.
... to be solved

Do you intend a difference in meaning or is it just an abbreviation. I mean, does this image solve those problems or no?

[chrisb]

Do you intend a difference in meaning or is it just an abbreviation. I mean, does this image solve those problems or no?

It's an abbreviation. "To be solved" itself is an abbreviation for "Set to the state solved".

It was very late and I wanted to go through all of the tickets at least once. Which I finally didn't because I thought the Dogleg vs. Levenberg-Marquart issues were something different.

[abdullah]

Do you intend a difference in meaning or is it just an abbreviation. I mean, does this image solve those problems or no?

It's an abbreviation. "To be solved" itself is an abbreviation for "Set to the state solved".

It was very late and I wanted to go through all of the tickets at least once. Which I finally didn't because I thought the Dogleg vs. Levenberg-Marquart issues were something different.

Ok!! Dogleg vs LM is indeed a separate issue. This appears at a second stage.

The solving comprises two stages, the first stage ("diagnose function") is the one that gives information about the rank of the matrix, the redundancies, conflicts. Eventually, if there are redundancies or conflicts, there is a Redundancy solve (via DogLeg or LM), but this is exceptional (only if there are redundancies/conflicts in the system). The second stage ("solve function") is the actual execution of DogLeg or LM to "move" the geometry to comply with the constraints.

This "LM succeeded where DogLeg failed" is because the second stage is implemented with a fallback position. This means that if DogLeg is the default solver and the solving fails, it tries to solve it with LM. In the specific case where DogLeg failed and LM succeeded, this appears in the report window. It is saying something like "hey, DogLeg is supposed to be superior to LM, but in this particular case it could not do the job, if somebody ever tries to review/improve the DogLeg implementation, it would be great that you report it so that that person is aware of this corner case for DogLeg".

From a user point of view, well LM succeeded and he's got his solution, so he is happy. Maybe it took a little bit more time, but today this is generally not like it was solving for such a long time. In the past it was indeed taking a long time due to the multiplier factor, but this is not a default today, DeepSOIC did some tests and came with the conclusion that increasing so much the iterations did not lead to convergence, something like "If it goes over 200 iterations without converging, it is almost certain that it is not going to converge, no matter if you wait for 1000 iterations or more, so why wait?".

I feel like an old grandpa telling old (four years old) stories

[abdullah]

Ok. I think it really solves a lot of issues, so I will propose this for merge now. You can still do checks or use it for your next DIY project. If you encounter any issue let me know. It will take time to merge as there is a substantial code to review.

https://github.com/FreeCAD/FreeCAD/pull/1429

[triplus]

As for:

https://freecadweb.org/tracker/view.php?id=2342

Dense: 3, 41
Sparse: 3, 40

Sometimes exiting/entering the sketcher edit mode is needed. As Update button doesn't update the 40 <-> 41. At that time we made a report. But the problem i guess is on how to know in such complex sketch if everything makes sense in the first place.

P.S. As for the 2170. Sorry it's not raining here today.

[abdullah]

As for:

https://freecadweb.org/tracker/view.php?id=2342

Dense: 3, 41
Sparse: 3, 40

Sometimes exiting/entering the sketcher edit mode is needed. As Update button doesn't update the 40 <-> 41. At that time we made a report. But the problem i guess is on how to know in such complex sketch if everything makes sense in the first place.

I am not sure I understand. With:

OS: Ubuntu 16.04.4 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13452 (Git)
Build type: None
Branch: master
Hash: 34633c144de9133c1f9aeb7da783f369cae9bfaf
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0

if I open the file with SparseQR I get "underconstrained with 1 DoF". If I do DenseQR, I get "redundant, remove 40".

With the AppImage, DenseQR says "redundant, remove 40", SparseQR says "redundant, remove 41".

The fact that it is 40 or 41 is a mere choice. As the decomposition is not going to be the same, because a QR decomposition is not unique, the choice of which one is redundant, from the set of "redundant constraints" may vary.

By looking at the sketch, it is not difficult to see that 40 and 41 are redundant, as they are vertical distance constraints on points that are symmetric about the Y axis. You may remove any of them achieving the same result.

In fact, I can provide now Bleigh "fixed":

blegh_fixed.fcstd

(7.02 KiB) Downloaded 36 times

Bleigh_fixed.png (121.79 KiB) Viewed 1164 times

It took me like 30 seconds. Remove what the solver says is redundant 41,82. Then use the DoF finder to locate the two arcs top/center. Radius constraint to one, and equal between them. Fully constraint (The experience is so cool for those of us that have ever suffered trying to fully constraint a complex sketch, that I cannot recommend enough to "live it". It is really rewarding. Open old Bleigh and give it a try... )

I think that this ticket is resolved

[chrisb]

I had thought your Appimage had only the new redundancy checker, and that solved most GSC tickets (if not all) in the tracker.

And now I see that the DOF finder is included as well! What a marvel!

Thank you very much. Although I have o confess that this tool will degrade the fame of forum regulars who can find tricky DOFs .

[abdullah]

I had thought your Appimage had only the new redundancy checker, and that solved most GSC tickets (if not all) in the tracker.

And now I see that the DOF finder is included as well! What a marvel!

Yes, I think it is a very good combination. The solver now is much more picky with redundants, and this will lead to better constraint sketches and many less problems. The DoF finder is really nice. Both make v0.18 already quite a good improvement over v0.17

BTW, my build was failing and I discovered that it was a unit test that was failing, because the old solver did not detect a redundancy and now it does, so a test that should have been failing like forever was not failing, and now because it fails, I realise that the test was wrong in the first place, so I just pushed a new commit for the unit test

Thank you very much. Although I have o confess that this tool will degrade the fame of forum regulars who can find tricky DOFs .

No need to thank. We all make FreeCAD.

P.S.: Well you will not be able to show off so often , but I am sure you will still have your opportunities . People will always need help... and the thing is that I am sure they will get it. What an awesome community we have!!

[chrisb]

What an awesome community we have!!

Yes, indeed. It is one of the very few which I have come across, where topics stay on topic (more or less), where people talk in a friendly tone all over the place (more), where hardly any personal attacks are found, and most important - where experts working daily with CAD systems share their knowledge.