Why does setting parameter bounds destroy this optimization?
95 views
Skip to first unread message
Rasmus
Mar 9, 2024, 4:51:22 AMMar 9
to Ceres Solver
I am trying to set parameter bounds for my problem, and I have observed that just setting the bounds makes the optimization not do anything, even though the initial values are well within the bounds.
The context is an ICP like problem, where I compute correspondences every iteration and optimize the relative transformation. I have narrowed this to just a translation and just the first ICP iteration to show the problem.
If I set parameter_tolerance and function_tolerance to 1e-3 and set the parameter bounds, the optimization does not do anything and cost does not change:
Solver Summary (v 2.1.0-eigen-(3.4.0)-lapack-suitesparse-(7.0.0)-cxsparse-(4.0.3)-acceleratesparse-eigensparse-no_openmp)
Original Reduced
Parameter blocks 1 1
Parameters 3 3
Residual blocks 1407 1407
Residuals 4221 4221
Minimizer TRUST_REGION
Dense linear algebra library EIGEN
Trust region strategy LEVENBERG_MARQUARDT
Given Used
Linear solver DENSE_QR DENSE_QR
Threads 1 1
Linear solver ordering AUTOMATIC 1
Cost:
Initial 9.861525e+02
Final 9.861525e+02
Change 0.000000e+00
Minimizer iterations 1
Successful steps 1
Unsuccessful steps 0
Line search steps 0
Time (in seconds):
Preprocessor 0.000090
Residual only evaluation 0.004039 (1)
Line search cost evaluation 0.000000
Jacobian & residual evaluation 0.022044 (2)
Line search gradient evaluation 0.010126
Linear solver 0.000134 (1)
Line search polynomial minimization 0.000000
Minimizer 0.026335
Postprocessor 0.000007
Total 0.026432
Termination: CONVERGENCE (Parameter tolerance reached. Relative step_norm: 4.668004e-04 <= 1.000000e-03.)
If I remove the parameter bounds, I get two minimizer iterations and the cost does decrease. Since these are not true correspondences, the cost is obviously nonzero.
Solver Summary (v 2.1.0-eigen-(3.4.0)-lapack-suitesparse-(7.0.0)-cxsparse-(4.0.3)-acceleratesparse-eigensparse-no_openmp)
Original Reduced
Parameter blocks 1 1
Parameters 3 3
Residual blocks 1407 1407
Residuals 4221 4221
Minimizer TRUST_REGION
Dense linear algebra library EIGEN
Trust region strategy LEVENBERG_MARQUARDT
Given Used
Linear solver DENSE_QR DENSE_QR
Threads 1 1
Linear solver ordering AUTOMATIC 1
Cost:
Initial 9.861525e+02
Final 9.696417e+02
Change 1.651080e+01
Minimizer iterations 2
Successful steps 2
Unsuccessful steps 0
Time (in seconds):
Preprocessor 0.000111
Residual only evaluation 0.000177 (2)
Jacobian & residual evaluation 0.000633 (2)
Linear solver 0.000203 (2)
Minimizer 0.001200
Postprocessor 0.000010
Total 0.001321
Termination: CONVERGENCE (Parameter tolerance reached. Relative step_norm: 4.668086e-08 <= 1.000000e-03.)
If I keep the parameter bounds and drop the parameter and function tolerance down to 1e-6, I get the same result as with higher tolerance and no bounds:
Solver Summary (v 2.1.0-eigen-(3.4.0)-lapack-suitesparse-(7.0.0)-cxsparse-(4.0.3)-acceleratesparse-eigensparse-no_openmp)
Original Reduced
Parameter blocks 1 1
Parameters 3 3
Residual blocks 1407 1407
Residuals 4221 4221
Minimizer TRUST_REGION
Dense linear algebra library EIGEN
Trust region strategy LEVENBERG_MARQUARDT
Given Used
Linear solver DENSE_QR DENSE_QR
Threads 1 1
Linear solver ordering AUTOMATIC 1
Cost:
Initial 9.861525e+02
Final 9.696417e+02
Change 1.651080e+01
Minimizer iterations 2
Successful steps 2
Unsuccessful steps 0
Line search steps 0
Time (in seconds):
Preprocessor 0.000048
Residual only evaluation 0.000092 (2)
Line search cost evaluation 0.000000
Jacobian & residual evaluation 0.000570 (4)
Line search gradient evaluation 0.000251
Linear solver 0.000096 (2)
Line search polynomial minimization 0.000000
Minimizer 0.000859
Postprocessor 0.000005
Total 0.000912
Termination: CONVERGENCE (Parameter tolerance reached. Relative step_norm: 4.668100e-08 <= 1.000000e-06.)
I've attached the code that reproduces the problem (see lines 54-66). It has a long list of points at the end but is otherwise short.
Could someone explain this behaviour?
Rasmus
Mar 13, 2024, 5:34:53 AMMar 13
to Ceres Solver
I also noticed (in the original, nonreduced problem for now), that setting parameter bounds behaves erratically even with the changes to the options. Even though the parameter initialization and point correspondence is always the same, on some runs the optimization works "normally" and on others, it changes the parameters to junk in the first invocation, and then of course this cannot be recovered from in the next iterations.
I'm not sure if i should report this behaviour as a bug, since this interaction of param bounds and other options isn't documented, but maybe this is obvious to everyone else?
Rasmus
Mar 14, 2024, 12:22:53 PMMar 14
to Ceres Solver
It seems that this problem does not occur in the same way when updating to current ceres master.
Sameer Agarwal
Jun 9, 2024, 1:17:22 PMJun 9
to ceres-...@googlegroups.com
Hi Folks,
Sorry for the delayed reply. Is this still an issue? as in does it disappear with the current ceres master? or does it manifest itself in a different way?
Sameer
--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/78a63203-f75a-4deb-938c-3581af52b6aan%40googlegroups.com.
Rasmus
Jun 30, 2024, 4:07:32 AM (5 days ago) Jun 30
to Ceres Solver
It does not occur as far as I can tell with current Ceres 2.2.0. I guess I could try to bisect the state that still failed, if that's of any interest.
Sameer Agarwal
Jun 30, 2024, 11:11:07 AM (5 days ago) Jun 30
to ceres-...@googlegroups.com
If you can bisect it, that would be great. It would be good to know what fixed it.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/cb5d869a-5022-41ee-a6a7-76fdab90879cn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages