================================================================================
Solves the part of this described bug relating to reference constraints affecting the diagnosis of redundant constraints:
https://forum.freecadweb.org/viewtopic.php?p=410195#p410195
Found via `codespell -q 3 -L aci,ake,aline,alle,alledges,alocation,als,ang,anid,ba,beginn,behaviour,bloaded,byteorder,calculater,cancelled,cancelling,cas,cascade,centimetre,childs,colour,colours,commen,currenty,dof,doubleclick,dum,eiter,elemente,feld,freez,hist,iff,indicies,initialisation,initialise,initialised,initialises,initialisiert,ist,kilometre,lod,mantatory,methode,metres,millimetre,modell,nd,noe,normale,normaly,nto,numer,oder,orgin,orginx,orginy,ot,pard,pres,programm,que,recurrance,rougly,seperator,serie,sinc,strack,substraction,te,thist,thru,tread,uint,unter,vertexes,wallthickness,whitespaces -S ./.git,*.po,*.ts,./ChangeLog.txt,./src/3rdParty,./src/Mod/Assembly/App/opendcm,./src/CXX,./src/zipios++,./src/Base/swig*,./src/Mod/Robot/App/kdl_cp,./src/Mod/Import/App/SCL,./src/WindowsInstaller,./src/Doc/FreeCAD.uml`
==============================================
In maximum verbose debug mode, information is given about the groups of Sketcher Constraints that the solver is considering for redundancy or conflict.
This is before the popularity contest selects the constraint shown in the solver messages.
The main reason for showing this is to enable to diagnose problems with sketches in which the constraint indicated as the redundant one appears not to
be the right one. Intended for power users with "iteration level" debug mode.
==============
- Zero initialization of the jacobian matrix
- Correct notification of redundant/conflicting in presence of non-driving constraints.
fixes#3529
==================================================
The solver uses some heuristics to determine the "redundant to remove" and notify it to the user.
Basically it would pick the solver redundant constraint that affects most groups of redundants (popularity contest).
In the simple cases, all the redundants are equally popular and the popularity contest is untied by using the tagid (let say for simplicity it is the number at sketcher level Constraint3, the tagid=3).
This means that in simple cases, the solver systematically decides that the redundant constraint to handle from those showing a linear dependency is the one appearing the last.
This commits changes the way to untie the popularity contest, by giving more priority to those sketcher constraints that need a lower number of solver constraints (in other words,
those constraints that remove a lower amount of DoF). In case of tie, the tagid is then used to break the tie.
At least:
fixes#3434fixes#1557
- Improve Debug information.
- Support for addition of constraints with driving information for the solver constraints.
- Removal of the driven constraints from the Jacobian for QR decomposition
- Removal of the value freewheeling parameter from the Jacobian for QR decomposition
- Full detection of dependent parameters where DoF are present for Dense QR.
Internal geometry knot points, which were added as fixed parameters to the solver according to a previous commit, are tracked in the corresponding bspline as solver level,
without being a parameter to the solver, and upon solving, the position thereof is updated by means of OCC functionality.
This allows to show the knot points and solidarily move them when moving a bspline.
The Ellipse radii solver constraint was reused generalised to MajorAxisConic class.
UI representation of the Equality sign not yet handled (appears on the origin).
- Fixing Hyperbola classes to get CCW emulation (like Ellipse classes).
In Sketcher:
- The Sketcher representation deals with the right branch of the Hyperbola only.
- Solver model is: Center, Focus1 (focus of the right branch), minor radius (b).
- HyperbolicArcRangeToEndPoints code is the one of Ellipse <= Awaiting DeepSOIC help ;)
- ConstraintPointOnHyperbola solver constraint is now implemented and should be working.
- No InternalAligment constraints implemented yet.
==================================================
This fix enables usage of the Eigen SparseQR starting in Eigen-3.3. It optimizes the code enabling it
to work with the new assignation interface of Eigen-3.3, which is more strict than that of Eigen-3.2.
It provides the same optimization for DenseQR code, and omits the extraction of the Q matrix in DenseQR
as this is not used anywhere else.
[NOTE: This is only to be merged after Debian has updated the Eigen-3.3-alpha1 package]
See:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12769&start=30#p104740https://forum.kde.org/viewtopic.php?f=74&t=129115
========================================================
This is an advanced setting just for allowing increased choices to power users that have problems with a given sketch and want to
test different flavours of DogLeg algorithm.
This commit does not change the default behaviour of FreeCAD. It is only intended to give more options to power users.
The advanced solver configuration is extended to support three different Gauss-newton steps for DogLeg:
FullPivLU => h_gn = Jx.fullPivLu().solve(-fx);
LeastNormFullPivLU => h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).fullPivLu().solve(-fx);
LeastNormLdlt => h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).ldlt().solve(-fx);
This setting is applied only to DogLeg. It is applied to DogLeg as normal or redundant solver, if DogLeg is the selected solver.
Selecting a solver different from DogLeg for both normal and redundant disables the setting.
We have been told:
https://forum.kde.org/viewtopic.php?f=74&t=129439#p346104
that our default Gauss-Newton step in DogLeg may not be adequate in general (we generally deal with underconstraint systems
unless we have a fully constraint sketch, and even then it is many times overconstraint at least for redundant solving).
We have been told that maybe these LeastNorm options are more suitable for us (performance set aside). This enables you as power
user to test if it works fine with FreeCAD.