Using PlaneGCS as the sketch constraint solver in SALOME

[cbourcier]

Regarding MED-file, its repository is not publicly available. It may change this year.

[Artem]

Hi all,

I'm a member of SHAPER development team, in charge of developing the connector between SHAPER and PlaneGCS.

The main problem we have faced is unstable behavior of Tangent constraint. Please take a look at two attached scripts, they only different by coordinates of elements. In fact, the sketch in tangent-ok.py has 7 DoF and completely solved. However, tangent-failed.py reports about 2 redundant constraints (both tangent) and has 9 DoF.

I would really appreciate it if somebody explains me the difference in these similar cases.

Thanks in advance.
Artem

[dbruniercoulin]

I've faced a similar problem using FreeCAD 0.16 interactively. For reproducing it, the sequence is the following:
- Open the attached model
- Edit the sketch
- Create a Tangent constraint between the arc and one of the 2 lines geometrically tangent

You get an over-constraint error message asking you to remove the Tangent constraint.

I guess the issue is the same than the one reported by Artem.

Can someone explain why the solver fails in this situation and if it can be fixed ?

[abdullah]

Hi all,

I'm a member of SHAPER development team, in charge of developing the connector between SHAPER and PlaneGCS.

The main problem we have faced is unstable behavior of Tangent constraint. Please take a look at two attached scripts, they only different by coordinates of elements. In fact, the sketch in tangent-ok.py has 7 DoF and completely solved. However, tangent-failed.py reports about 2 redundant constraints (both tangent) and has 9 DoF.

I would really appreciate it if somebody explains me the difference in these similar cases.

Thanks in advance.
Artem

Nice example.

First, which version of FC are you using? I tell you because in the ubuntu daily build (v17) that I use, your scripts won't work because Part.Line is not a sketcher supported time, it has to be linesegment, like this:

Code: Select all

App.ActiveDocument.Sketch.addGeometry(Part.LineSegment(App.Vector(-544.3181818181816,-159.0909090909091,0),App.Vector(-336.809445115132,101.6251959975382,0)),False)
App.ActiveDocument.Sketch.addGeometry(Part.LineSegment(App.Vector(-227.3938145270301, 96.31134256163281,0),App.Vector(-37.49999999999997, -196.5909090909091,0)),False)

I am also asking for the version, because I do not know if your version has the advanced solver dialog, which provides additional debug information and allows you to switch between algorithms:

AdvancedSolverDialog.png (157.51 KiB) Viewed 1544 times

In any case I can reproduce the issue in your examples.

One observation, that does not justify in any way why it does not work, is that I would not have used tangent that way for endpoint tangency. There is a specific construction for this that does not require the coincident constraints (in the UE select the end points where you want the tangency and hit tangent constraint):

Code: Select all

App.ActiveDocument.Sketch.addConstraint(Sketcher.Constraint('Tangent',0,2,2,2)) 
App.ActiveDocument.Sketch.addConstraint(Sketcher.Constraint('Tangent',1,1,2,1)) 

which such construction your failing sketch does not fail anymore (just remove the coincidents and tangents with the two lines above).

Now back to your real question: I do not know why and it would be great to know why.

I can comment on what I see. This is the solver debugging information for your ok script:

EigenSparseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-13, Params: 17, Constr: 10, Rank: 10
Sketcher::setUpSketch()-T:0.001
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-17, dogLegGaussStep: FullPivLU, xsize: 13, csize: 6, maxIter: 200
DL: stopcode: 1, Success
Sketcher::Solve()-DogLeg-T:0

There are two algorithms for the QR factorization, which determines the conflict/redundant status of the sketch, the EigenSparseQR and the EigenDenseQR. Basically it is a QR factorization for determining the Rank of the solver matrix and uses the Eigen library to calculate them. You can switch among them in the advanced solver dialog. The additional parameter that plays a role is the "Pivot Threshold", which basically indicates how low a number must be so that the QR factorization considers it to be zero.

So one could say that the Rank result is a consequence of:
a) The solver matrix (it is interesting for the QR specially how well conditioned the matrix actually is).
b) The algorithm used (Dense or Sparse)
c) The pivot threshold

The above debugging information is with FC default values. Now, lets see what happens with the "failed" dossier.

Default parameters:

Code: Select all

EigenSparseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-13, Params: 17, Constr: 10, Rank: 8
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, dogLegGaussStep: FullPivLU, xsize: 13, csize: 8, maxIter: 100
DL: stopcode: 1, Success
Sketcher::RedundantSolving-DogLeg-
Sketcher Redundant solving: 2 redundants
Sketcher::setUpSketch()-T:0
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-17, dogLegGaussStep: FullPivLU, xsize: 9, csize: 4, maxIter: 200
DL: stopcode: 1, Success
Sketcher::Solve()-DogLeg-T:0

DenseQR provides the same result:

Code: Select all

DenseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-13, Params: 17, Constr: 10, Rank: 8
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, dogLegGaussStep: FullPivLU, xsize: 13, csize: 8, maxIter: 100
DL: stopcode: 1, Success
Sketcher::RedundantSolving-DogLeg-
Sketcher Redundant solving: 2 redundants
Sketcher::setUpSketch()-T:0
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-17, dogLegGaussStep: FullPivLU, xsize: 9, csize: 4, maxIter: 200
DL: stopcode: 1, Success
Sketcher::Solve()-DogLeg-T:0

Increasing the Pivot Threshold (sometimes) shows that the rank increases (still by one), so the matrix probably is bad conditioned:

Code: Select all

DenseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-15, Params: 17, Constr: 10, Rank: 9
DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, dogLegGaussStep: FullPivLU, xsize: 15, csize: 9, maxIter: 100

Somebody wanting to get to the bottom of this, probably should take a look at the input matrix and its QR decomposition, that with 17 parameters and 10 constraints. You have two very nice scripts one ok and the other failing, so it might be possible to draw some conclusion by comparing the matrices...

I am very interested in anything you may find

[abdullah]

I would really appreciate it if somebody explains me the difference in these similar cases.

Another thing that I hate about this solver issues is:

1. Run your failing script
2. Select a point with the mouse a drag it (it will move without respecting the tangency)
3. Now hit the "solve" button in the advanced solver dialog or recompute

You get a perfectly solved sketch:

Code: Select all

DenseQR, Threads: 1, Vectorization: On, Pivot Threshold: 1e-20, Params: 17, Constr: 10, Rank: 10
Sketcher::setUpSketch()-T:0.001

I wanted to try this, because "out of experience", when I have a misbehaving sketch (which is usually related to tangencies), just dragging those tangency points (even in cases where the sketch is totally constraint and the just won't move) fixes issues (not being able to pad the sketch with "broken face" error).

[abdullah]

I've faced a similar problem using FreeCAD 0.16 interactively. For reproducing it, the sequence is the following:
- Open the attached model
- Edit the sketch
- Create a Tangent constraint between the arc and one of the 2 lines geometrically tangent

You get an over-constraint error message asking you to remove the Tangent constraint.

I guess the issue is the same than the one reported by Artem.

Can someone explain why the solver fails in this situation and if it can be fixed ?

This is exactly the same issue. You can interactively "solve it" following the instructions I have just given (contingency plan). If by fixing you actually mean preventing it from happening, that will probably have to do with Artem's findings

[DeepSOIC]

This had been explained multiple times, almost every time a user would post a project where some Boolean operation fails, or sweep fails, and the project can be repaired by replacing coincident+tangent with endpoint-to-endpoint tangent.

There is a little bit of explanation on Constraint Tangent wiki page. This isn't a comprehensive explanation, it is just stating the poor solver convergence of coincident+tangent combination.

The reason is very similar to what happens to Newton's method of finding a root. It works properly when plot y(x) pierces X axis, when derivative is nonzero. However, if asked to solve y=x^2, the method converges very slowly because of derivative tending to zero. Result is poor accuracy of solution. And if solution is accurate enough, derivative is zero. Since solver uses derivatives when DOF counting, the constraint effectively disappears from matrix if the solution happens to be precise enough.

point-to-point tangent uses different mathematical formulation of the constraint combination, avoiding the problem.

[HoWil]

Dear FreeCAD developers,
The SALOME team (CEA-EDF) is currently developing a new parametric modeller for numerical simulation to replace SALOME GEOM.
Christophe

Hi all,
I'm a member of SHAPER development team, in charge of developing the connector between SHAPER and PlaneGCS.
Artem

Dear Christophe, Dear Artem,

I am a user of both FreeCAD and Salome. I wonder if it would not be better to create something like a (live-) link/an interface between FreeCAD and Salome to use the best form both worlds than creating a second FC inside Salome. FC would benefit form a advanced meshing environment while Salome does not have to re-invent a parametric modeler.
Sorry for hijacking your post! Never the less it is good if bugs are closed together .

BR,
HoWil

[Artem]

Dear abdullah, Dear DeepSOIC,

Thanks for your comments, they are appreciated a lot. In fact, we have tried point-to-point tangency and it shows a great results.

Regarding the cases I have reported in my previous message. It is very strange for me that similar cases has different result. Indeed the result depends on the solver. I will try to investigate this problem at leisure.

Thank you one again!

[abdullah]

Regarding the cases I have reported in my previous message. It is very strange for me that similar cases has different result. Indeed the result depends on the solver. I will try to investigate this problem at leisure.

Thank you one again!

You are welcome!!

I think DeepSOIC is absolutely right. From a solver perspective, it might be possible to change the tangency constraint definition so that it produces higher module derivatives when a coincident constraint is present. From an integration perspective, it should be possible to detect such situation (concident + edge tangency) and automagically substitute it with and endpoint-to-endpoint tangency.

Let us know your progress!!
abdullah