Adventure of fixing sketcher solver for large sketches

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Adventure of fixing sketcher solver for large sketches

Post by DeepSOIC »

It all started with a sketch posted by @dimitar here: https://forum.freecadweb.org/viewtopic.php?f=3&t=39276
I thought I could fix the problem by scaling constraint error functions, to make them all return values of similar magnitudes.
So, I made this:
https://github.com/DeepSOIC/FreeCAD-ell ... ntScaling1
I scaled down all error functions by dividing stuff by the size of the sketch.
Unfortunately, the results are underwhelming. While the sketch by @dimitar is successfully solved with the changed constraint definitions, there is a big new problem: dragging arcs of circles is now very very jittery on any sketch of substantial size.
jittery_arc.gif
jittery_arc.gif (286.5 KiB) Viewed 3310 times
So, my guesses:
* (1) the solver uses some junk from memory
or
* (2) the solver is for some reason very unstable with this scaling applied
I have added some debug output for scaling calls, these seem to be all right. So I think (1) isn't the problem.

As for (2): maybe, the solver changes angle-like unknows way too fast. I just have no idea really. Maybe I should be scaling unknowns so that they are all in the same ballpark instead of scaling the errors. So, a thing to try is to simply scale the whole sketch down so that it is around 1 mm in size for solving purposes.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Adventure of fixing sketcher solver for large sketches

Post by openBrain »

I can find several older threads where solver breaks due to sketch dimension magnitude of you want to run other tests. ;)
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Adventure of fixing sketcher solver for large sketches

Post by DeepSOIC »

openBrain wrote: Wed Oct 30, 2019 7:54 pm I can find several older threads where solver breaks due to sketch dimension magnitude of you want to run other tests. ;)
Yes please, although I am not really ready for torture-testing the thing.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Adventure of fixing sketcher solver for large sketches

Post by DeepSOIC »

I have instructed the solver to limit the angle change per step, but that doesn't seem to help a lot :cry:
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Adventure of fixing sketcher solver for large sketches

Post by ickby »

Back then when I tried to write a 3d solver for assemblies I failed for that very reason: standard numeric solvers are unable to cope with the fact that rotational and transitional degrees of freedom have different sensitivities, a unit change in the parameter leads to to massively different changes in the sketch dependent on the type of parameter. So the sensitivity for translation to translation is always 1, angle to angle also always 1, but angle to translation may be way higher. That is a unsolvable problem, as reducing the angle sensitivities may solve angle to translation problem, but than created a angle to angle sensitivity problem, as this gets way too small or big dependet on scaling. Another issue is that one solver variable is part of many output dofs, hence you would need different scaling for each single output dof but have only one scaling factor for the variable. There was a very nice easy to read paper about that, but can't find it anymore...

I always thought the 2d solver did not have this problem, as all variables in the sketch have been translations (only point x,y coordinates as free variables), obviously that changed (I looked last 5 years ago :lol:). But that could be a possible solution, maybe you can rewrite some of the angle variables in a way it only uses translational dofs?

As a note, all free 3d assembly solvers have this problem. e.g. for solvespace you can easily construct problems that makes it fail all the time just by choosing the sizes of parts.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Adventure of fixing sketcher solver for large sketches

Post by DeepSOIC »

ickby wrote: Thu Oct 31, 2019 7:01 am Another issue is that one solver variable is part of many output dofs, hence you would need different scaling for each single output dof but have only one scaling factor for the variable. There was a very nice easy to read paper about that, but can't find it anymore...
Not sure I understand. Is it about an assembly/sketch with a long dangly chain of parts stuck to each other, like spider leg?
japie
Posts: 163
Joined: Thu Jun 26, 2014 5:49 am

Re: Adventure of fixing sketcher solver for large sketches

Post by japie »

Where can I find the solver code guys?
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Adventure of fixing sketcher solver for large sketches

Post by DeepSOIC »

japie wrote: Thu Oct 31, 2019 4:01 pm Where can I find the solver code guys?
See GCS.cpp. And a bit in SubSystem.cpp.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Adventure of fixing sketcher solver for large sketches

Post by chrisb »

And here is some documentation from Abdullah: https://github.com/abdullahtahiriyo/Fre ... chitecture
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
japie
Posts: 163
Joined: Thu Jun 26, 2014 5:49 am

Re: Adventure of fixing sketcher solver for large sketches

Post by japie »

Thanks!

had a quick look at the docs and it looks like it's a pretty solid system, only downfall is that every change the full sketch is solved again not only "affected" points by the change but that still doesn't explain why the process is to slow, will look at the code when I have some spare time but I am not a real coder just a guy with fresh look so probably will ask some dumb things. ;-) (or nothing if I don't see something odd)
Post Reply