Hi guys!!

Please forgive my silence. I am busy implementing the internal geometry alignment constraint.

For the moment a teaser, the one giving a major axis to the ellipse (yes that angle is a normal angle constraint!!):

Hi guys!!

Please forgive my silence. I am busy implementing the internal geometry alignment constraint.

For the moment a teaser, the one giving a major axis to the ellipse (yes that angle is a normal angle constraint!!):

Please forgive my silence. I am busy implementing the internal geometry alignment constraint.

For the moment a teaser, the one giving a major axis to the ellipse (yes that angle is a normal angle constraint!!):

Hi again!

I have just finished the InternalAlignment constraints implementation.

Code here:

https://github.com/abdullahtahiriyo/Fre ... master.git

* [new branch] sketcher_ellipse_general_alignment_to_internal_geometry_contraint

How does it look like? How can I use it?

I am reusing the "phase constraint" icon.

1. create an ellipse

2. create any combination of two points and two lines.

3. select the lines and the point and the ellipse and click the "phase constraint" (take care not to select the points at the ends of the lines)

How is this implemented inside?

A new constraint type was created. The constraint system was extended to code a subtype. Every internal alignment constraint is a solver constraint (some very easy as focus1, it is just a pointcoincident constraint), for the others I have calculated the error function and the partials. For example, for the major axis, I have implemented an error function that is the sum of the errors of the vector between the +a point of the ellipse and point1 and the +a point of the ellipse and point2, wherein point1 and point2 are the extremes of a line. Similar for minoraxis. F2 is just the error of the position of F2 calculated from the other model parameters minus P1, all squared...

All this error functions are "squared" to avoid having roots...

Where can I find this math work?

Here: First impressions:

I am totally disappointed. I never expected such a poor performance. After putting the internal construction elements (all of them), it is a nightmare to try to move the ellipse. Even trying to put an angle to the major axis seems to make the solver fail. This happens, I think, because every change in one element triggers a change in all the other elements, and every change in all the other elements in all the others, as with this architecture, all depend on all.

For me, unless any of you has a brilliant idea, this is a no go. It seems to me like a nice theoretical idea which belongs to the group of the nice theoretical ideas that work... only on paper

Please let me know your impressions and any idea you might have... I am already looking for alternatives...

N.B.: Note that the reason of creating all this "internal geometry" is avoiding to have ellipse specific constraints, i.e. major axis is the length of the line on the major axis, same for minor axis, and an angle can be set between the major axis and the X axis (for example). Putting only one or two elements does not solve the problems when a fully constraint ellipse is necessary...

I have just finished the InternalAlignment constraints implementation.

Code here:

https://github.com/abdullahtahiriyo/Fre ... master.git

* [new branch] sketcher_ellipse_general_alignment_to_internal_geometry_contraint

How does it look like? How can I use it?

I am reusing the "phase constraint" icon.

1. create an ellipse

2. create any combination of two points and two lines.

3. select the lines and the point and the ellipse and click the "phase constraint" (take care not to select the points at the ends of the lines)

How is this implemented inside?

A new constraint type was created. The constraint system was extended to code a subtype. Every internal alignment constraint is a solver constraint (some very easy as focus1, it is just a pointcoincident constraint), for the others I have calculated the error function and the partials. For example, for the major axis, I have implemented an error function that is the sum of the errors of the vector between the +a point of the ellipse and point1 and the +a point of the ellipse and point2, wherein point1 and point2 are the extremes of a line. Similar for minoraxis. F2 is just the error of the position of F2 calculated from the other model parameters minus P1, all squared...

All this error functions are "squared" to avoid having roots...

Where can I find this math work?

Here: First impressions:

I am totally disappointed. I never expected such a poor performance. After putting the internal construction elements (all of them), it is a nightmare to try to move the ellipse. Even trying to put an angle to the major axis seems to make the solver fail. This happens, I think, because every change in one element triggers a change in all the other elements, and every change in all the other elements in all the others, as with this architecture, all depend on all.

For me, unless any of you has a brilliant idea, this is a no go. It seems to me like a nice theoretical idea which belongs to the group of the nice theoretical ideas that work... only on paper

Please let me know your impressions and any idea you might have... I am already looking for alternatives...

N.B.: Note that the reason of creating all this "internal geometry" is avoiding to have ellipse specific constraints, i.e. major axis is the length of the line on the major axis, same for minor axis, and an angle can be set between the major axis and the X axis (for example). Putting only one or two elements does not solve the problems when a fully constraint ellipse is necessary...

But that is the case for every minor complex sketch, that is the whole point of the solver and in general he should be able to solve such situations without problems. What you need to look out for are the values in the jacobian of the system. Are there any that are much bigger than 1? If so chances are good that you created a non-metric parameter space and then, well, hell is open Numerical solvers in general handle such cases not very well.This happens, I think, because every change in one element triggers a change in all the other elements, and every change in all the other elements in all the others, as with this architecture, all depend on all

I am not seing (like right now) such high values in the Jacobian (matrix of gradients)...

Howeve, nothing in the partials prevents them from returning high values... and the code:

However, what I do see above is that many rows have very low values, to the point of looking bad conditioned to me (as other rows have 1s). I am very ignorant about this, so my question is, do I have to take any measure so that the partials returned by the constraints are somehow "normalized" to something?

Thanks!!

Abdullah

P.S.+ Edit: Sorry "non-metric parameter space". Do you mean by this that all the magnitudes should have units of mm as opposed to mm^2... in several places we are using as error functions length squared functions... maybe it has nothing to do... I am just asking...

Code: Select all

```
0 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 1 0 0 -1 0 0 0 0 0 0 0 0 0 0
2.98996e-11 5.30918e-11 -1.49498e-11 -2.65459e-11 0 0 0 -1.49498e-11 -2.65459e-11 0 0 0 0 0 0 0 0
-5.98011e-10 1.41154e-10 3.81651e-10 -3.7159e-10 -3.76543e-12 0 0 0 0 0 0 0 0 6.11067e-12 2.12367e-10 0 0
5.21689e-10 -7.04267e-11 -2.79763e-10 2.748e-10 4.45552e-11 0 0 0 0 -5.12017e-11 6.25278e-13 0 0 0 0 0 0
```

does not seem to take any measures to prevent the Jacobian from having high values, if the partials provide high values.Eigen::MatrixXd J(clist.size(), plist.size());

int count=0;

for (std::vector<Constraint *>::iterator constr=clist.begin();

constr != clist.end(); ++constr) {

(*constr)->revertParams();

if ((*constr)->getTag() >= 0) {

count++;

for (int j=0; j < int(plist.size()); j++)

J(count-1,j) = (*constr)->grad(plist[j]);

}

}

#ifdef _GCS_DEBUG

// Debug code starts

std::stringstream stream;

stream << J ;

const std::string tmp = stream.str();

Base::Console().Warning(tmp.c_str());

// Debug code ends

#endif

However, what I do see above is that many rows have very low values, to the point of looking bad conditioned to me (as other rows have 1s). I am very ignorant about this, so my question is, do I have to take any measure so that the partials returned by the constraints are somehow "normalized" to something?

Thanks!!

Abdullah

P.S.+ Edit: Sorry "non-metric parameter space". Do you mean by this that all the magnitudes should have units of mm as opposed to mm^2... in several places we are using as error functions length squared functions... maybe it has nothing to do... I am just asking...

No, definitly not. The Jacobian has to be filled with the correct values, modifying them in any way will break the solver. Values >> 1 would just indicate a hard to solve system of equations, thats why it is good to look out for them. If it is not the case than it actually should work.I am very ignorant about this, so my question is, do I have to take any measure so that the partials returned by the constraints are somehow "normalized" to something?

What I see in your Jacobi is that equations 3, 4 and 5 are basicly not influences by any parameter. I regard 1e-10 as 0. This is very strange, if those equation would have a error value there is basicly no way that the solver can change that as he does not see any possible influence, hat could make everything that slow or make it fail.

Assuming your gradients are calculated correctly and the functions are actually dependend on the parameters what could have happend is that your initial values for the parameters are choosen in such a way that the gradient of the equations is zero. A zero gradient imeans not a zero error value! It is just a property of most error functions that they have a zero gradient for all parameters at some point in the parameter space. That needs to be treaded. In the assembly solver code I have a special algorithm which handles this, you would need something similar.

Ok. I will go with the: my initial values are not ok. Why? because when I apply the constraint to the far away construction lines and points, it easily converges...

... where may I find your assembly branch? also, what does it mean non-metric system?

... where may I find your assembly branch? also, what does it mean non-metric system?

Hi Abdullah

on sourceforge the latest Assembly branch is jriegel/dev-assembly2

here

http://sourceforge.net/p/free-cad/code/ ... y2/~/tree/

Jim

on sourceforge the latest Assembly branch is jriegel/dev-assembly2

here

http://sourceforge.net/p/free-cad/code/ ... y2/~/tree/

Jim

You mentioned: all errors are sqared. It could be a problem, if the solver has to converge to a mimimum. I think this is not handled well with the newton method.

Ulrich

Ulrich

Code: Select all

```
1646 double ConstraintInternalAlignmentEllipseFocus2::error()
1647 {
1648 // so first is to select the point (X_0,Y_0) in line to calculate
1649 double X_1 = *p1x();
1650 double Y_1 = *p1y();
1651 double X_c = *cx();
1652 double Y_c = *cy();
1653 double X_F1 = *f1x();
1654 double Y_F1 = *f1y();
1655 double b = *rmin();
1656
1657 double err=pow(X_1 + X_F1 - 2*X_c, 2) + pow(Y_1 + Y_F1 - 2*Y_c, 2);
1658 return scale * err;
1659 }
```

EDIT: by double zero, I mean that it looks like a parabola that only touches abscissa axis. A good error function should cross the abscissa at an angle.

EDIT2:

Code: Select all

```
1508 double ConstraintInternalAlignmentEllipseMinorDiameter::error()
...
1521 double err=pow(X_1 - X_c + b*(Y_F1 - Y_c)/sqrt(pow(X_F1 - X_c, 2) +
1522 pow(Y_F1 - Y_c, 2)), 2) + pow(-X_2 + X_c + b*(Y_F1 - Y_c)/sqrt(pow(X_F1
1523 - X_c, 2) + pow(Y_F1 - Y_c, 2)), 2) + pow(-Y_1 + Y_c + b*(X_F1 -
1524 X_c)/sqrt(pow(X_F1 - X_c, 2) + pow(Y_F1 - Y_c, 2)), 2) + pow(Y_2 - Y_c +
1525 b*(X_F1 - X_c)/sqrt(pow(X_F1 - X_c, 2) + pow(Y_F1 - Y_c, 2)), 2);
1526 return scale * err;
```

I compiled your latest branch

sketcher_ellipse_general_alignment_to_internal_geometry_contraint

one thing I noticed is that there is a vertex on the ellipse. Is that intended?

Jim

OS: Ubuntu 14.04.1 LTS

Word size of OS: 64-bit

Word size of FreeCAD: 64-bit

Version: 0.15.4030 (Git)

Branch: sketcher_ellipse_general_alignment_to_internal_geometry_contraint

Hash: efcb2a36027a0608d8a445c0b02e4fb049f2a5a4

Python version: 2.7.6

Qt version: 4.8.6

Coin version: 4.0.0a

SoQt version: 1.6.0a

OCC version: 6.7.1

sketcher_ellipse_general_alignment_to_internal_geometry_contraint

one thing I noticed is that there is a vertex on the ellipse. Is that intended?

Jim

OS: Ubuntu 14.04.1 LTS

Word size of OS: 64-bit

Word size of FreeCAD: 64-bit

Version: 0.15.4030 (Git)

Branch: sketcher_ellipse_general_alignment_to_internal_geometry_contraint

Hash: efcb2a36027a0608d8a445c0b02e4fb049f2a5a4

Python version: 2.7.6

Qt version: 4.8.6

Coin version: 4.0.0a

SoQt version: 1.6.0a

OCC version: 6.7.1