Sketcher: Ellipse support

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
ickby
Posts: 2961
Joined: Wed Oct 05, 2011 7:36 am

Re: Sketcher: Ellipse support

Postby ickby » Thu Feb 11, 2016 6:54 pm

Took a look. Edge-to-edge tangency+coincident is the bad way of constraining a sketch. It causes a double zero of error function, which causes poor convergence.
But if that is a problem and it does not converge it should result in solving failure. If the solver succeeds it means that the given abortion criteria is fullfilled, that the needed precission is reached. This is the case for the given sketch. Now it showed that the successfully solved sketch does not meet the occ criteria. This means that either the sketcher abortion criteria is too high or that the error function does compute something different than what occ uses for tangency comparison. Both cases would be solver problems and should be fixed.
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Sketcher: Ellipse support

Postby DeepSOIC » Thu Feb 11, 2016 7:35 pm

This is next to impossible, because precision of double is only about 1e-15, while error function precision required here would be 1e-12^2 == 1e-24 (squared, because of double zero). Another option is to ban edge-to-edge tangency completely.
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Sketcher: Ellipse support

Postby DeepSOIC » Thu Feb 11, 2016 7:40 pm

To clarify: the line is actually made tangent to ellipse, but in a point slightly different from the point of connection.
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Sketcher: Ellipse support

Postby DeepSOIC » Thu Feb 11, 2016 7:45 pm

One interesting way is to make solver work in extended precision, which not only will make it more precise, but also slightly faster (afaik, x86 processors operate in extended precision internally, and working in double precision involves extra processing of rounding down). At least it was so quite a long time ago; as for current state of things - I'm not sure.