Great!abdullah wrote:As said, I am pursuing notifying Eigen Developers of the LUFullPiv issue here:

https://forum.kde.org/viewtopic.php?f=74&t=129439

Let's see what happens...

Great!abdullah wrote:As said, I am pursuing notifying Eigen Developers of the LUFullPiv issue here:

https://forum.kde.org/viewtopic.php?f=74&t=129439

Let's see what happens...

I have forced updated the branch (long story, was not intentional):

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

This branch, apart from the adaptation to Eigen-3.3 (to be merged when Debian has a non-buggy Eigen), also has the code I wrote to extract the c++ code necessary for creating a Subsystem equal to the one of a (failing) Sketch. This code can be easily embedded in a project like this:

https://github.com/abdullahtahiriyo/Eig ... onvergence

Such a project depends only on Eigen.

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

This branch, apart from the adaptation to Eigen-3.3 (to be merged when Debian has a non-buggy Eigen), also has the code I wrote to extract the c++ code necessary for creating a Subsystem equal to the one of a (failing) Sketch. This code can be easily embedded in a project like this:

https://github.com/abdullahtahiriyo/Eig ... onvergence

Such a project depends only on Eigen.

If you will check the question you asked it was already answered. And it was answered with style i might add. Amazing!abdullah wrote:I have forced updated the branch (long story, was not intentional):

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

This branch, apart from the adaptation to Eigen-3.3 (to be merged when Debian has a non-buggy Eigen), also has the code I wrote to extract the c++ code necessary for creating a Subsystem equal to the one of a (failing) Sketch. This code can be easily embedded in a project like this:

https://github.com/abdullahtahiriyo/Eig ... onvergence

Such a project depends only on Eigen.

Sorry, I do not understand. Which question? Where was it answered?triplus wrote:If you will check the question you asked it was already answered. And it was answered with style i might add. Amazing!abdullah wrote:I have forced updated the branch (long story, was not intentional):

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

This branch, apart from the adaptation to Eigen-3.3 (to be merged when Debian has a non-buggy Eigen), also has the code I wrote to extract the c++ code necessary for creating a Subsystem equal to the one of a (failing) Sketch. This code can be easily embedded in a project like this:

https://github.com/abdullahtahiriyo/Eig ... onvergence

Such a project depends only on Eigen.

EDIT: You mean that ggael has replied to me in the kde forum?

About that answer:

https://forum.kde.org/viewtopic.php?f=7 ... 50#p346069

Gael (ggael) is extremely helpful. I really like him. Not that I fully understand everything he always replies. I guess that for that I should have more math knowledge.

https://forum.kde.org/viewtopic.php?f=7 ... 50#p346050

and tell me which OS and Eigen version you are compiling against. I am going to do some tests (I use Ubuntu).

I think this can be a great opportunity for the sketcher to improve (and maybe I learn a bit more about math in the meantime)...

EDIT 2: If somebody could do this compilation under OS (what Gael uses), I am curious to see what happens in OS.

EDIT 3: So far I have tried Eigen versions:

eigen-eigen-b30b87236a1b-3.2.7

eigen-eigen-ca142d0540d3-3.1.0

eigen-eigen-ffa86ffb5570-3.2.0

in addition to Eigen 3.3 of 5/11/2015 (7832:ef9fac3eb614).

I systematically get the failure to converge with all of them...

I am running:

Ubuntu 14.04.3 LTS

GCC:

I have tried building with optimization levels 00 and 03 (make -e VERBOSE=1 CPPFLAGS=-O0):

Code: Select all

```
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
```

Code: Select all

```
gcc -Q --help=optimizers
The following options control optimizations:
-O<number>
-Ofast
-Og
-Os
-faggressive-loop-optimizations [enabled]
-falign-functions [disabled]
-falign-jumps [disabled]
-falign-labels [disabled]
-falign-loops [disabled]
-fasynchronous-unwind-tables [enabled]
-fbranch-count-reg [enabled]
-fbranch-probabilities [disabled]
-fbranch-target-load-optimize [disabled]
-fbranch-target-load-optimize2 [disabled]
-fbtr-bb-exclusive [disabled]
-fcaller-saves [disabled]
-fcombine-stack-adjustments [disabled]
-fcommon [enabled]
-fcompare-elim [disabled]
-fconserve-stack [disabled]
-fcprop-registers [disabled]
-fcrossjumping [disabled]
-fcse-follow-jumps [disabled]
-fcx-fortran-rules [disabled]
-fcx-limited-range [disabled]
-fdata-sections [disabled]
-fdce [enabled]
-fdefer-pop [disabled]
-fdelayed-branch [disabled]
-fdelete-null-pointer-checks [enabled]
-fdevirtualize [disabled]
-fdse [enabled]
-fearly-inlining [enabled]
-fexceptions [disabled]
-fexpensive-optimizations [disabled]
-ffinite-math-only [disabled]
-ffloat-store [disabled]
-fforward-propagate [disabled]
-fgcse [disabled]
-fgcse-after-reload [disabled]
-fgcse-las [disabled]
-fgcse-lm [enabled]
-fgcse-sm [disabled]
-fgraphite-identity [disabled]
-fguess-branch-probability [disabled]
-fhandle-exceptions
-fhoist-adjacent-loads [disabled]
-fif-conversion [disabled]
-fif-conversion2 [disabled]
-finline [enabled]
-finline-atomics [enabled]
-finline-functions [disabled]
-finline-functions-called-once [disabled]
-finline-small-functions [disabled]
-fipa-cp [disabled]
-fipa-cp-clone [disabled]
-fipa-profile [disabled]
-fipa-pta [disabled]
-fipa-pure-const [disabled]
-fipa-reference [disabled]
-fipa-sra [disabled]
-fira-hoist-pressure [enabled]
-fivopts [enabled]
-fjump-tables [enabled]
-floop-block [disabled]
-floop-interchange [disabled]
-floop-nest-optimize [disabled]
-floop-parallelize-all [disabled]
-floop-strip-mine [disabled]
-fmath-errno [enabled]
-fmerge-all-constants [disabled]
-fmerge-constants [disabled]
-fmodulo-sched [disabled]
-fmove-loop-invariants [enabled]
-fnon-call-exceptions [disabled]
-fnothrow-opt [disabled]
-fomit-frame-pointer [disabled]
-fopt-info [disabled]
-foptimize-register-move [disabled]
-foptimize-sibling-calls [disabled]
-foptimize-strlen [disabled]
-fpack-struct [disabled]
-fpack-struct=<number>
-fpeel-loops [disabled]
-fpeephole [enabled]
-fpeephole2 [disabled]
-fpredictive-commoning [disabled]
-fprefetch-loop-arrays [enabled]
-freg-struct-return [disabled]
-fregmove [disabled]
-frename-registers [enabled]
-freorder-blocks [disabled]
-freorder-blocks-and-partition [disabled]
-freorder-functions [disabled]
-frerun-cse-after-loop [disabled]
-freschedule-modulo-scheduled-loops [disabled]
-frounding-math [disabled]
-frtti [enabled]
-fsched-critical-path-heuristic [enabled]
-fsched-dep-count-heuristic [enabled]
-fsched-group-heuristic [enabled]
-fsched-interblock [enabled]
-fsched-last-insn-heuristic [enabled]
-fsched-pressure [disabled]
-fsched-rank-heuristic [enabled]
-fsched-spec [enabled]
-fsched-spec-insn-heuristic [enabled]
-fsched-spec-load [disabled]
-fsched-spec-load-dangerous [disabled]
-fsched-stalled-insns [disabled]
-fsched-stalled-insns-dep [enabled]
-fsched2-use-superblocks [disabled]
-fschedule-insns [disabled]
-fschedule-insns2 [disabled]
-fsection-anchors [disabled]
-fsel-sched-pipelining [disabled]
-fsel-sched-pipelining-outer-loops [disabled]
-fsel-sched-reschedule-pipelined [disabled]
-fselective-scheduling [disabled]
-fselective-scheduling2 [disabled]
-fshort-double [disabled]
-fshort-enums [enabled]
-fshort-wchar [disabled]
-fshrink-wrap [disabled]
-fsignaling-nans [disabled]
-fsigned-zeros [enabled]
-fsingle-precision-constant [disabled]
-fsplit-ivs-in-unroller [enabled]
-fsplit-wide-types [disabled]
-fstrict-aliasing [disabled]
-fstrict-enums [disabled]
-fthread-jumps [disabled]
-fno-threadsafe-statics [enabled]
-ftoplevel-reorder [enabled]
-ftrapping-math [enabled]
-ftrapv [disabled]
-ftree-bit-ccp [disabled]
-ftree-builtin-call-dce [disabled]
-ftree-ccp [disabled]
-ftree-ch [disabled]
-ftree-coalesce-inlined-vars [disabled]
-ftree-coalesce-vars [enabled]
-ftree-copy-prop [disabled]
-ftree-copyrename [disabled]
-ftree-cselim [enabled]
-ftree-dce [disabled]
-ftree-dominator-opts [disabled]
-ftree-dse [disabled]
-ftree-forwprop [enabled]
-ftree-fre [disabled]
-ftree-loop-distribute-patterns [disabled]
-ftree-loop-distribution [disabled]
-ftree-loop-if-convert [enabled]
-ftree-loop-if-convert-stores [disabled]
-ftree-loop-im [enabled]
-ftree-loop-ivcanon [enabled]
-ftree-loop-optimize [enabled]
-ftree-lrs [disabled]
-ftree-partial-pre [disabled]
-ftree-phiprop [enabled]
-ftree-pre [disabled]
-ftree-pta [enabled]
-ftree-reassoc [enabled]
-ftree-scev-cprop [enabled]
-ftree-sink [disabled]
-ftree-slp-vectorize [enabled]
-ftree-slsr [disabled]
-ftree-sra [disabled]
-ftree-switch-conversion [disabled]
-ftree-tail-merge [disabled]
-ftree-ter [disabled]
-ftree-vect-loop-version [enabled]
-ftree-vectorize [disabled]
-ftree-vrp [disabled]
-funit-at-a-time [enabled]
-funroll-all-loops [disabled]
-funroll-loops [disabled]
-funsafe-loop-optimizations [disabled]
-funsafe-math-optimizations [disabled]
-funswitch-loops [disabled]
-funwind-tables [disabled]
-fvar-tracking [enabled]
-fvar-tracking-assignments [enabled]
-fvar-tracking-assignments-toggle [disabled]
-fvar-tracking-uninit [disabled]
-fvariable-expansion-in-unroller [disabled]
-fvect-cost-model [disabled]
-fvpt [disabled]
-fweb [enabled]
-fwhole-program [disabled]
-fwrapv [disabled]
```

Code: Select all

```
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 6200.14
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
```

Gael proposes some possible modifications to DogLeg regarding FullPivotLU:

This one converges without any need of Eigen override in 10 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).fullPivLu().solve(-fx);

This one converges without any need of Eigen override in 7 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).ldlt().solve(-fx);

I will try to make that tests a bit latter. As for:

P.S. Anyway take your time as i guess there is a lot of new things to understand based on new insights.

Regardless of the outcome of the tests should/could this be considered as solution if it always converged? Or could using this introduce issues with redundant/conflicting constraints?EDIT 4:

Gael proposes some possible modifications to DogLeg regarding FullPivotLU:

This one converges without any need of Eigen override in 10 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).fullPivLu().solve(-fx);

This one converges without any need of Eigen override in 7 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).ldlt().solve(-fx);

P.S. Anyway take your time as i guess there is a lot of new things to understand based on new insights.

I was just about to start compiling:

https://forum.kde.org/viewtopic.php?f=7 ... 39#p346104

https://bitbucket.org/eigen/eigen/commits/616017adf663/

P.S: I will do one compile anyway to see if it really takes only 30s.

https://forum.kde.org/viewtopic.php?f=7 ... 39#p346104

https://bitbucket.org/eigen/eigen/commits/616017adf663/

P.S: I will do one compile anyway to see if it really takes only 30s.

Yeah, probably not necessary anymore, but I tried your test with a couple different compilers anyway. Here are the results.

OS X, Apple LLVM version 6.1.0 (clang-602.0.37), eigen 3.2.6

I get the same results as ggael -- both options converge the same.

Debian Jessie, clang-3.5, eigen 3.2.2

Same results as you -- only OLD_FULLPIVLU converges.

Debian Jessie, gcc-4.9, eigen 3.2.2

Same results as you -- only OLD_FULLPIVLU converges.

Windows 7, msvc 9 x86, eigen 3.2.1

Same results as you -- only OLD_FULLPIVLU converges.

Strangely, I couldn't get it to run with 64-bit msvc:

I couldn't get it to compile with gcc 5.2 on OS X, something to do with an assembly instruction, so I'm not sure if it is the compiler or OS X that makes the difference.

Edit: it works with i686-apple-darwin10-llvm-g++-4.2 too, but it is not actual gcc, so probably doesn't mean much.

OS X, Apple LLVM version 6.1.0 (clang-602.0.37), eigen 3.2.6

I get the same results as ggael -- both options converge the same.

Debian Jessie, clang-3.5, eigen 3.2.2

Same results as you -- only OLD_FULLPIVLU converges.

Debian Jessie, gcc-4.9, eigen 3.2.2

Same results as you -- only OLD_FULLPIVLU converges.

Windows 7, msvc 9 x86, eigen 3.2.1

Same results as you -- only OLD_FULLPIVLU converges.

Strangely, I couldn't get it to run with 64-bit msvc:

Code: Select all

```
Populating values for the relevant Subsystem
Creating the Subsystem
Solving using DogLeg
DL: tolg: 1e-080, tolx: 1e-080, tolf: 1e-010, convergence: 1e-010, xsize: 172, csize: 171, maxIter: 100
DL: stopcode: 0, Failed
```

I couldn't get it to compile with gcc 5.2 on OS X, something to do with an assembly instruction, so I'm not sure if it is the compiler or OS X that makes the difference.

Edit: it works with i686-apple-darwin10-llvm-g++-4.2 too, but it is not actual gcc, so probably doesn't mean much.

Some additional information to what @peterl94 provided. I have used this branch on Ubuntu 14.04:

https://github.com/abdullahtahiriyo/Eig ... onvergence

And didn't change any settings in it. It did compile under 30s and the result did fail to converge. I didn't test this any further.

After i have used this branch:

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

With Eigen-dev branch containing the mentioned fix. Opening the blegh.fcstd file and entering in the sketcher edit mode works fast!

P.S. There still is the difference in solver messages noticed when opening the sketch in edit mode if DenseQR/SparseQR is used and everything else is set at default settings.

https://github.com/abdullahtahiriyo/Eig ... onvergence

And didn't change any settings in it. It did compile under 30s and the result did fail to converge. I didn't test this any further.

After i have used this branch:

https://github.com/abdullahtahiriyo/Fre ... n3.3-fix_2

With Eigen-dev branch containing the mentioned fix. Opening the blegh.fcstd file and entering in the sketcher edit mode works fast!

P.S. There still is the difference in solver messages noticed when opening the sketch in edit mode if DenseQR/SparseQR is used and everything else is set at default settings.

Tested with MSVC 9, gcc-4.6.3 and clang-3.0 with Eigen3.1.4, 3.2.5 and 3.3-alpha1.

When setting the the define OLD_FULLPIVLU compilation always failed for me!?

Without OLD_FULLPIVLU the result are:

**MSVC**

Eigen3.1.4, Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-080, tolx: 1e-080, tolf: 1e-010, convergence: 1e-010, xsize: 172, csize: 171, maxIter: 100

DL: stopcode: 0, Failed

Eigen3.3 doesn't compile at all.

**gcc-4.6.3**

Eigen3.1.4, Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 3.81571e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 3.81571e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114274, g_inf(tolg): 0.000104323, delta(f(tolx)): 0.15, err(divergingLim): 2.7646e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112383, g_inf(tolg): 9.15021e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.22945e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108387, g_inf(tolg): 8.14153e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.06251e-08

...

DL, Iteration: 97, fx_inf(tolf): 4.88172e-05, g_inf(tolg): 1.78131e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.5589e-09

DL, Iteration: 98, fx_inf(tolf): 4.86666e-05, g_inf(tolg): 1.77665e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.53241e-09

DL, Iteration: 99, fx_inf(tolf): 4.85673e-05, g_inf(tolg): 1.77387e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.50684e-09

DL: stopcode: 4, Failed

Eigen3.3:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 5.01991e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 5.01991e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114152, g_inf(tolg): 0.000100878, delta(f(tolx)): 0.15, err(divergingLim): 3.37895e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112493, g_inf(tolg): 8.36503e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.71141e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108401, g_inf(tolg): 7.92818e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.50615e-08

...

DL, Iteration: 96, fx_inf(tolf): 5.01867e-05, g_inf(tolg): 1.74165e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.31459e-09

DL, Iteration: 97, fx_inf(tolf): 5.01789e-05, g_inf(tolg): 1.74077e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.2948e-09

DL, Iteration: 98, fx_inf(tolf): 5.01694e-05, g_inf(tolg): 1.73662e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.27528e-09

DL, Iteration: 99, fx_inf(tolf): 5.01622e-05, g_inf(tolg): 1.73602e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.25661e-09

DL: stopcode: 4, Failed

**clang3.0**

Eigen3.1.4,Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 3.81571e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 3.81571e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114274, g_inf(tolg): 0.000104323, delta(f(tolx)): 0.15, err(divergingLim): 2.7646e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112383, g_inf(tolg): 9.15021e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.22945e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108387, g_inf(tolg): 8.14153e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.06251e-08

...

DL, Iteration: 96, fx_inf(tolf): 4.89258e-05, g_inf(tolg): 1.78311e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.58611e-09

DL, Iteration: 97, fx_inf(tolf): 4.88172e-05, g_inf(tolg): 1.78131e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.5589e-09

DL, Iteration: 98, fx_inf(tolf): 4.86666e-05, g_inf(tolg): 1.77665e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.53241e-09

DL, Iteration: 99, fx_inf(tolf): 4.85673e-05, g_inf(tolg): 1.77387e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.50684e-09

DL: stopcode: 4, Failed

Eigen3.3:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 5.01991e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 5.01991e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114152, g_inf(tolg): 0.000100878, delta(f(tolx)): 0.15, err(divergingLim): 3.37895e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112493, g_inf(tolg): 8.36503e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.71141e-08

...

DL, Iteration: 97, fx_inf(tolf): 5.01789e-05, g_inf(tolg): 1.74077e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.2948e-09

DL, Iteration: 98, fx_inf(tolf): 5.01694e-05, g_inf(tolg): 1.73662e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.27528e-09

DL, Iteration: 99, fx_inf(tolf): 5.01622e-05, g_inf(tolg): 1.73602e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.25661e-09

DL: stopcode: 4, Failed

When setting the the define OLD_FULLPIVLU compilation always failed for me!?

Without OLD_FULLPIVLU the result are:

Eigen3.1.4, Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-080, tolx: 1e-080, tolf: 1e-010, convergence: 1e-010, xsize: 172, csize: 171, maxIter: 100

DL: stopcode: 0, Failed

Eigen3.3 doesn't compile at all.

Eigen3.1.4, Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 3.81571e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 3.81571e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114274, g_inf(tolg): 0.000104323, delta(f(tolx)): 0.15, err(divergingLim): 2.7646e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112383, g_inf(tolg): 9.15021e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.22945e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108387, g_inf(tolg): 8.14153e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.06251e-08

...

DL, Iteration: 97, fx_inf(tolf): 4.88172e-05, g_inf(tolg): 1.78131e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.5589e-09

DL, Iteration: 98, fx_inf(tolf): 4.86666e-05, g_inf(tolg): 1.77665e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.53241e-09

DL, Iteration: 99, fx_inf(tolf): 4.85673e-05, g_inf(tolg): 1.77387e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.50684e-09

DL: stopcode: 4, Failed

Eigen3.3:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 5.01991e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 5.01991e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114152, g_inf(tolg): 0.000100878, delta(f(tolx)): 0.15, err(divergingLim): 3.37895e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112493, g_inf(tolg): 8.36503e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.71141e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108401, g_inf(tolg): 7.92818e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.50615e-08

...

DL, Iteration: 96, fx_inf(tolf): 5.01867e-05, g_inf(tolg): 1.74165e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.31459e-09

DL, Iteration: 97, fx_inf(tolf): 5.01789e-05, g_inf(tolg): 1.74077e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.2948e-09

DL, Iteration: 98, fx_inf(tolf): 5.01694e-05, g_inf(tolg): 1.73662e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.27528e-09

DL, Iteration: 99, fx_inf(tolf): 5.01622e-05, g_inf(tolg): 1.73602e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.25661e-09

DL: stopcode: 4, Failed

Eigen3.1.4,Eigen3.2.5:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 3.81571e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 3.81571e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114274, g_inf(tolg): 0.000104323, delta(f(tolx)): 0.15, err(divergingLim): 2.7646e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112383, g_inf(tolg): 9.15021e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.22945e-08

DL, Iteration: 4, fx_inf(tolf): 0.000108387, g_inf(tolg): 8.14153e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.06251e-08

...

DL, Iteration: 96, fx_inf(tolf): 4.89258e-05, g_inf(tolg): 1.78311e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.58611e-09

DL, Iteration: 97, fx_inf(tolf): 4.88172e-05, g_inf(tolg): 1.78131e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.5589e-09

DL, Iteration: 98, fx_inf(tolf): 4.86666e-05, g_inf(tolg): 1.77665e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.53241e-09

DL, Iteration: 99, fx_inf(tolf): 4.85673e-05, g_inf(tolg): 1.77387e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 4.50684e-09

DL: stopcode: 4, Failed

Eigen3.3:

Solving using DogLeg

DL: tolg: 1e-80, tolx: 1e-80, tolf: 1e-10, convergence: 1e-10, xsize: 172, csize: 171, maxIter: 100

DL, Iteration: 0, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.3, err(divergingLim): 5.01991e-08

DL, Iteration: 1, fx_inf(tolf): 0.000120285, g_inf(tolg): 0.000210914, delta(f(tolx)): 0.15, err(divergingLim): 5.01991e-08

DL, Iteration: 2, fx_inf(tolf): 0.000114152, g_inf(tolg): 0.000100878, delta(f(tolx)): 0.15, err(divergingLim): 3.37895e-08

DL, Iteration: 3, fx_inf(tolf): 0.000112493, g_inf(tolg): 8.36503e-05, delta(f(tolx)): 0.15, err(divergingLim): 2.71141e-08

...

DL, Iteration: 97, fx_inf(tolf): 5.01789e-05, g_inf(tolg): 1.74077e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.2948e-09

DL, Iteration: 98, fx_inf(tolf): 5.01694e-05, g_inf(tolg): 1.73662e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.27528e-09

DL, Iteration: 99, fx_inf(tolf): 5.01622e-05, g_inf(tolg): 1.73602e-05, delta(f(tolx)): 0.0421875, err(divergingLim): 9.25661e-09

DL: stopcode: 4, Failed

Thank you to all so much for your testing so far.

**About failure to compile**

1. May you double check that you are using this**master** branch (I have another branch with some other trials)?

https://github.com/abdullahtahiriyo/Eig ... onvergence

2. Are you setting the macro** EIGEN_3_3_OR_BEYOND** accordingly?

//#define OLD_FULLPIVLU // This enforces old legacy FullPivLU::compute method

#define EIGEN_3_3_OR_BEYOND // if you are using eigen 3.3 or higher this must be set, if you are using eigen 3.2 this must be unset.

I mean, with OLD_FULLPIVLU**unset**, the code should **always** compile for any version of the library, regardless of the EIGEN_3_3_OR_BEYOND macro being set or unset (because the latter is only used within the former). However, with the OLD_FULLPIVLU **set**, it is mandatory that you **unset** the EIGEN_3_3_OR_BEYOND when you are using any Eigen-3.2.X or 3.1.X, or you will have a compilation error having to do with a change in the declaration of FullPivLU:Compute. Similarly, for the case of Eigen_3.3.X, EIGEN_3_3_OR_BEYOND must be **set**.

3. What is your platform? Windows, Linux, OSX?

4. When it did not compile with MSVC without the OLD_FULLPIVLU with Eigen3.3(3.3-alpha1), may you tell me which is the main complaint of the compiler, when it does not compile? You are much more knowledgeable in general and in particular regarding MSVC, do you have a clue why gcc compiled it and MSVC did not?

I only tested Ubuntu (I do have access neither to Windows nor OSX). One note, peter managed to compile it in Windows and notified this.

**About the result of MSVC,. when it compiled**

It is weird that it failed with stopcode 0 and it did not print a single iteration, but it is exactly the same peterl94 is reporting for 64 bits MSVC:

This is the closest to MSVC that has been reported:

**Further tests**

Could any of you try to use Eigen-3.3 directly from mercurial (hg clone http://bitbucket.org/eigen/eigen), to test the fix Gael just released in other platforms? I have done it in Ubuntu (I assume triplus also did it in Ubuntu). For me, this converges in a couple of iterations.

**FreeCAD future development**

I am currently quite interested in just understanding the issue with Eigen and try to provide Gael with the most accurate information, so that he can figure out if something in Eigen needs further fixing. However:

This is really unexpected... Compilation should not be a problem.wmayer wrote:When setting the the define OLD_FULLPIVLUcompilationalways failed for me!?

1. May you double check that you are using this

https://github.com/abdullahtahiriyo/Eig ... onvergence

2. Are you setting the macro

//#define OLD_FULLPIVLU // This enforces old legacy FullPivLU::compute method

#define EIGEN_3_3_OR_BEYOND // if you are using eigen 3.3 or higher this must be set, if you are using eigen 3.2 this must be unset.

I mean, with OLD_FULLPIVLU

3. What is your platform? Windows, Linux, OSX?

4. When it did not compile with MSVC without the OLD_FULLPIVLU with Eigen3.3(3.3-alpha1), may you tell me which is the main complaint of the compiler, when it does not compile? You are much more knowledgeable in general and in particular regarding MSVC, do you have a clue why gcc compiled it and MSVC did not?

I only tested Ubuntu (I do have access neither to Windows nor OSX). One note, peter managed to compile it in Windows and notified this.

It is weird that it failed with stopcode 0 and it did not print a single iteration, but it is exactly the same peterl94 is reporting for 64 bits MSVC:

This is the closest to MSVC that has been reported:

peterl94 wrote:Windows 7, msvc 9 x86, eigen 3.2.1

Same results as you -- only OLD_FULLPIVLU converges.

It would be great if we could narrow this failure down a little. If it is an eigen issue, I am rather sure Gael will be more than interested in fixing it.peterl94 wrote:Strangely, I couldn't get it to run with 64-bit msvc:

Code: Select all

Populating values for the relevant Subsystem

Creating the Subsystem

Solving using DogLeg

DL: tolg: 1e-080, tolx: 1e-080, tolf: 1e-010, convergence: 1e-010, xsize: 172, csize: 171, maxIter: 100

DL: stopcode: 0, Failed

Could any of you try to use Eigen-3.3 directly from mercurial (hg clone http://bitbucket.org/eigen/eigen), to test the fix Gael just released in other platforms? I have done it in Ubuntu (I assume triplus also did it in Ubuntu). For me, this converges in a couple of iterations.

I am currently quite interested in just understanding the issue with Eigen and try to provide Gael with the most accurate information, so that he can figure out if something in Eigen needs further fixing. However:

I regard Gael as an expert in this field. If he says that our current approach is not the most appropriate one, I am quite confident that he is right. I am interested in these solutions, but first I will buy me a book on the topic (I accept advice on which one) and try to understand it.triplus wrote:As for:

EDIT 4:

Gael proposes some possible modifications to DogLeg regarding FullPivotLU:

This one converges without any need of Eigen override in 10 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).fullPivLu().solve(-fx);

This one converges without any need of Eigen override in 7 iterations:

h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).ldlt().solve(-fx);

Regardless of the outcome of the tests should/could this be considered as solution if it always converged? Or could using this introduce issues with redundant/conflicting constraints?

P.S. Anyway take your time as i guess there is a lot of new things to understand based on new insights.

Yes, the solution arrived to by DenseQR and SparseQR (that is somehow unrelated to the current issue) is different for the case of blegh.fcstd. This issue should be studied separately.triplus wrote:P.S. There still is the difference in solver messages noticed when opening the sketch in edit mode if DenseQR/SparseQR is used and everything else is set at default settings.