Opened 22 months ago
Last modified 16 months ago
#992 assigned enhancement
Improve bound Levenberg-Marquardt solver
Reported by: | butler | Owned by: | pkienzle |
---|---|---|---|
Priority: | major | Milestone: | SasView 4.3.0 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | SasView Fitting Redesign |
Description
Marcelo, a user from Argentina recently pointed out that in SasView 4.1.2 the optimizer did not respect the min/max bounds at all.
Paul Kienzle subsequently pointed out that the bumps implementation of LM doe NOT in fact respect those limits while the other optimizers do. This seems very wrong since LM is the primary optimizer used at least to start and one would expect that given the option to enter bounds they have some meaning.
Paul says this should be an "easy" fix? It would be nice to have that fixed in 4.2. Presumably this requires changes to bumps not SasView?
Change History (3)
comment:1 Changed 17 months ago by butler
- Owner set to pkienzle
- Status changed from new to assigned
comment:2 Changed 16 months ago by pkienzle
- Milestone changed from SasView 4.2.0 to SasView 4.3.0
- Priority changed from critical to major
- Summary changed from Upgrade bumps so that LM optimizer respects bounds to Improve bound Levenberg-Marquardt solver
- Type changed from defect to enhancement
comment:3 Changed 16 months ago by pkienzle
The mpfit branch of bumps repo has bindings to mpfit.
Should rewrite so that numerical derivatives can make use of distributed mapping function.
Should use LAPACK QR decomposition rather than doubly nested for-loops in python (use scipy.linalg.qr since numpy.linalg.qr does not support pivoting, and pivoting can give a couple more bits of accuracy on the generally ill-conditioned Jacobian).
Bumps parameters are already implementing tied and fitted conditions, so this complexity isn't needed in the base L-M solver.
Looking at the code, bumps does indeed implement bounds when I wrapped scipy's Levenberg-Marquardt.
Testing on latex spheres in usans (test/1d_data/latex_smeared.xml[1]) with sphere radius [2300, inf) it finds a best fit of 2323.5; setting the range to [2400, inf) returns a fit result of 2400 when started at various values. Additionally constraining scale to [0.01, inf) gives poor fit performance at the boundary (i.e., no progress by LM, even if the radius constraint is relaxed); mpfit performs much better in this situation.
Since the current version does not appear to be broken (just underperforming) I've changed the ticket title, lowered the priority and moved it to the next release.