Using PlaneGCS as the sketch constraint solver in SALOME

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
cbourcier
Posts: 5
Joined: Wed Jan 04, 2017 10:29 am

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by cbourcier »

Regarding MED-file, its repository is not publicly available. It may change this year.
Artem
Posts: 2
Joined: Fri Mar 10, 2017 1:48 pm

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by 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
Attachments
tangency-failed.py
(1.73 KiB) Downloaded 90 times
tangency-ok.py
(1.72 KiB) Downloaded 83 times
dbruniercoulin
Posts: 1
Joined: Wed Mar 15, 2017 4:01 pm

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by 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 ?
Attachments
ExactArc.FCStd
(3.2 KiB) Downloaded 70 times
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by abdullah »

Artem wrote: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
AdvancedSolverDialog.png (157.51 KiB) Viewed 2925 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
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by abdullah »

Artem wrote: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
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by abdullah »

dbruniercoulin wrote: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 ;)
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by 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
Veteran
Posts: 1279
Joined: Sun Jun 14, 2015 7:31 pm
Location: Austria

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by HoWil »

cbourcier wrote:Dear FreeCAD developers,
The SALOME team (CEA-EDF) is currently developing a new parametric modeller for numerical simulation to replace SALOME GEOM.
Christophe
Artem wrote: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 8-) .

BR,
HoWil
Artem
Posts: 2
Joined: Fri Mar 10, 2017 1:48 pm

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by 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
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Using PlaneGCS as the sketch constraint solver in SALOME

Post by abdullah »

Artem wrote: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
Post Reply