Not sure if this might help but a similar issue occurs with iterative numerical solving of differential equations. One part of an equation solves nicely with technique A but the other part of the equation does not. Likewise, the other part of the equation solves nicely with technique B but the first part does not. So both techniques are combined in an "operator splitting" approach. Here is a video:ickby wrote: ↑Thu Oct 31, 2019 7:01 am 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...
Adventure of fixing sketcher solver for large sketches
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 439
- Joined: Tue Apr 04, 2017 6:06 pm
- Location: SF Bay Area, California
Re: Adventure of fixing sketcher solver for large sketches
Re: Adventure of fixing sketcher solver for large sketches
Thank you for this post. All these problems i can confirm and found them during development of my 3D solver within the A2plus WB. As the solver of A2plus is not a standard numeric solver and each constraint is coded separatly, often the boundbox size of a part is taken into calculation, to avoid scaling dimensions effects. But i still have numerical stability issues, especially on long dof chains.ickby wrote: ↑Thu Oct 31, 2019 7:01 am 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.
I think similar effects may affect the 2D sketch solver.
KBWBE
https://github.com/kbwbe/A2plus
latest release: v0.4.56, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
https://github.com/kbwbe/A2plus
latest release: v0.4.56, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
Re: Adventure of fixing sketcher solver for large sketches
Hi All,
In some cad such as rhino the user must select between 2 obj sizes during creation of a file, one for small objs with high precision and the othet one for large objs with high max dimensions available. If I remember right the switch is at 3mt. So the number of digits is the same , it changes the number of integer digits.
I think exactly for the same reason You reported in the thread.
My 2 cents
Valerio
In some cad such as rhino the user must select between 2 obj sizes during creation of a file, one for small objs with high precision and the othet one for large objs with high max dimensions available. If I remember right the switch is at 3mt. So the number of digits is the same , it changes the number of integer digits.
I think exactly for the same reason You reported in the thread.
My 2 cents
Valerio
Re: Adventure of fixing sketcher solver for large sketches
Creo is unit-less.
in the properties a unit is set but it is just a calculation property for mass etc but it don't use it for shapes.
result is that the only problem is large delta's between small and large surfaces(tesselation). let's say you have a cone with a diameter of 1.5 m and a radii inside it of 3 mm or so...
in the properties a unit is set but it is just a calculation property for mass etc but it don't use it for shapes.
result is that the only problem is large delta's between small and large surfaces(tesselation). let's say you have a cone with a diameter of 1.5 m and a radii inside it of 3 mm or so...
Re: Adventure of fixing sketcher solver for large sketches
If you are reimplementing the solver, will you consider unequalities as well to prevent sketches from the well known flipping?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
- 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
I am considering that. But it's on low priority. I.e., you'll likely see a working solver before I get busy with inequalities, if at all.
Re: Adventure of fixing sketcher solver for large sketches
No problem, I just wanted to raise awareness.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.