==================================================================================
Why?
if lastDoF<0, then an over-constrained situation has ensued and geometry is not to be updated, as geometry can not follow the constraints.
However, solver information needs to be updated.
Solution:
Just trigger a constraint change so that signaling is sent to ViewProviderSketch via boost and the solver information updated, using
Constraints.touch().
==================================================
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
- basic infrastructure for handling of expressions
- port the unit properties editor to support expressions
- port placement editor to support expressions
- expressions for double spinbox
- expressions in sketch constraints
=========================================
The problem:
Mirror stopped working.
How to reproduce:
Select a sketch, and apply "Mirror Sketch" from the menu.
Why?
With the introduction of expressions, mirror sketch stopped working. The reason is that mirror functionality did use the "clone" function to make copies of constraints
and then modify their values. After expessions introduction, which introduces a unique tag per constraint, this copy was regarded as a "rename" of the original constraint
as they shared the unique tag.
Fix?
New function "copy()" for a constraint, that copies all the content but the tag.
========================================================
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.
===================================================
This commit sets the sketch size multiplier OFF by default (so the number of iterations DogLeg/BGFS/LM is not sketch size dependent).
In complicated sketches having a high number of parameters, with sketch multiplier on, the number of iterations is extremely high (100 parameters*100 iterations => 10000 iterations).
The idea of disabling this comes from tests performed by DeepSOIC and from my own experience using the Sketcher. In general
sketch multiplier makes FreeCAD unresposive (very high amount of iterations, not a real freeze) in big sketches so that users
end up killing the application. This is preventing the users from taking appropriate action, Developers from getting the information of the failure and
users angry.
The idea is that even for complicated sketchs N iterations (100 by default) should be enough to converge, if it is ever going to converge. Experience will tell us
if we have to increase this number in the range [100-300]. 100 iterations in complicated dossiers is in my experience generally under 30 seconds.
N.B.: This commit does not change the defaults stored in your computer, so if you have the sketcher multiplier on, the advanced solver dialog will still enforce this local setting. You
may disable it or click the "defaults" button to disable the sketcher multiplier.
===================================================================
It allows to export the c++ code to create a subsystem with the same information as the one solved using LM/DL/BGFS.
In this commit the functionality is disabled (for production).
To enable the functionality uncomment this line in planegcs/Constraints.h:
//#define _GCS_EXTRACT_SOLVER_SUBSYSTEM_
When enabled, upon solving with LM/DL/BGFS, the c++ code to generate the subsystem is added to a subsystem.txt that is created in the FreeCAD
execution directory.
Note that the file is created in append mode, so it will append all normal/redundant solvings until the file is deleted.
The resulting code can be directly pasted into a project similar to:
https://github.com/abdullahtahiriyo/Eigen_LUPiv_Convergence
Such a project only has libeigen as external dependency.
