Adventure of fixing sketcher solver for large sketches

[Mark Szlazak]

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...

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:

phpBB [video]

[kbwbe]

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.

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.

I think similar effects may affect the 2D sketch solver.

[Turro75]

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

[Jee-Bee]

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...

[chrisb]

If you are reimplementing the solver, will you consider unequalities as well to prevent sketches from the well known flipping?

[DeepSOIC]

If you are reimplementing the solver, will you consider unequalities as well to prevent sketches from the well known flipping?

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.

[chrisb]

No problem, I just wanted to raise awareness.