========================================================
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.
=========================================================================
This fixes issue:
http://www.freecadweb.org/tracker/view.php?id=2281
Discussed in:
http://forum.freecadweb.org/viewtopic.php?p=101910#p101910
How to reproduce?
With Auto-Update mode unchecked, execute the sequence in the bug tracker. You will reach to a geometry assembly successfully solved that can not be moved.
Why?
The coincident constraint is partially redundant within the meaning of redundancy of the solver.
The solve within "addconstraint" in SketchObjectPy.cpp causes the geometry to move to meet the coincident constraint.
At the end of the solve, the initial solution used in diagnostics is no longer valid (the geometry moved). This causes a subsequente move not to be executed.
The Solution:
Recalculate just the initial solution after the addition.
=====================================
When the solver converged (but did not succeed) or when the solver succeded but the solution is not OCC-valid, no error message was shown in the solver messages dialog.
=====================================================================
Issue:
http://freecadweb.org/tracker/view.php?id=2292
Constraints dissapear after a sketch loses support
Steps To Reproduce:
1. Make a sketch on a face.
2. Constrain it
3. Select "reorient sketch"
4. Do you want to lose support? Yes
5. Click cancel on the reorientation dialog.
6. Enter edit mode: No constraints...
Why?
GeoUndef not checked when deleting all external geometry (on dettaching from the support).
Solution:
Check for GeoUndef.
===================================================
The bug was introduced by myself here:
47c0859c1b
[code]
void SketchObject::onDocumentRestored()
{
try {
- rebuildExternalGeometry();
+ if(Support.getValue()) {
+ validateExternalLinks();
+ rebuildExternalGeometry();
+ }
Constraints.acceptGeometry(getCompleteGeometry());
}
[/code]
The issue is that "rebuildExternalGeometry" calls "rebuildVertexIndex". So for any sketch not having external geometry, if you open it, select everything and hit del, you will have a crash because
I effectively removed the creation of the index in this dossier. You won't have one if you do anything rebuilding the index before hitting del, like creating geometry, though.
================================================
Issue reported inter alia here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12380#p99456
How to reproduce:
1. Make an external geometry hexagon (make a hexagon, pad it, make a sketch on a hexagonal face and make all the lines external geometry)
2. Box select the external lines and press "del"
On the first pressing of "del" 3 lines were deleted and 3 remained, select again, on the second press 1 remains, select again, on the last press all are deleted.
Why?
Internal and External geometry were handled together in a single set. Group deletion of geometry is effected starting from the highest index,
so that upon deleting an element, the index of the remaining elements does not change. Handling both groups together caused that the external geometry
was actually deleted on the inversed order (as they are (decreasing) negative values for representation, but increasing positive indexes in the external geometry array).
Solution:
Internal and External geometries are handled separatedly
+ fix SoAutoZoomTranslation and SoZoomTranslation to get correct scaling factor
(do not rely on active view because this can be the wrong one and thus delivers wrong results)
=================================================================
First bug: Inability to create links to external geometry as described here:
http://forum.freecadweb.org/download/file.php?id=16668
Second bug: FC crashes on changing the support after having imported external geometry as described here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12380
and solving this ticket:
http://www.freecadweb.org/tracker/view.php?id=2225
Solution to first bug:
If for some reason a sketch ends up having a list of external geometries (property) that can not be recreated (rebuilt),
they remain latent, do not show the external elements in the elements widget or in the screen and prevent adding the
elements again.
In cases where the saved file contains invalid external geometry links (which will give raise to a handled exception that would prevent external geometry creation),
this condition gets detected during restore and the invalid links are deleted before external geometry creation, so as to allow the rest of external links to be recreated.
Solution to second bug:
It is also related to invalid external links (the link was existing, but upon change on the support, it is possible that an external edge is no longer valid, reduction of edges in support).
This situation is detected upon entering into edit mode, and the invalid ones are deleted.
Note that there is still the possibility for the user to remap an invalid sketch BEFORE editing, if the remapping is successful, it may not be necessary to delete links (all depends on the
specific case).
==============================================================================
What is this?
method
getCoincidentPoints
actually only included (as indicated in the documentation comment) those points coincident by a single constraint.
That is not "all the coincident points".
However some methods currently using it are expecting exactly that (coincident points linked by a single constraint).
A new method is introduced:
const std::map<int, Sketcher::PointPos> getAllCoincidentPoints(int GeoId, PointPos PosId);
that provides all the points coincident with the given one, directly (via a single constraint) or indirectly (via multiple coincident constraints).
The old method is renamed to:
getDirectlyCoincidentPoints
So as to have a more meaningful name to differentiate between both methods.
======================================================================
1. SketchObject::arePointsCoincident upgraded to check for indirect coincidence.
2. Coincidence constraint creation now checks for indirect coincidences and avoids
creating redundant coincidence constraints (for example during box selection).
=====================================================================================
This fixes a bug related to:
http://www.freecadweb.org/tracker/view.php?id=2093
that during creation of a geometric element if a vertical/horiz autoconstraint is to be enforced, it is not enforced if the endpoints of the geometric element under creation are
coincident with external geometry.
According to the discussion here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12254&sid=eacf5bdee068cb71cc54dc5a62a6849d&start=20#p99359
this fixes the bug.
It does not fulfil the request on the ticket as it was decided to still allow an explicit addition of a vertical/horizontal constraint, as
it may be needed in some cases and the user expects to be able to add them, even if it will lead to an overconstrained sketch.
How to reproduce?
1. Create a rectange
2. Pad it
3. Create a new sketch on a face
4. link two corners as "external geometry" (but not the ones of a diagonal)
5. Create a line coincident with the first and second corners, so that the line is horizontal or vertical
In master it will force horiz or vert leading to a overconstrained sketch.
With this patch, the horiz/vert will not be enforced in this case.
