Project

General

Profile

Bug #24078

update LMFit.status after a fit ends in exception

Added by James Stapleton about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
High
Assignee:
-
Start date:
02/20/2020
Due date:
% Done:

0%

Estimated time:
Duration:

Description

  1. setup stuff & create fitter named twiggle_fit
  2. call twiggle_fit.fit() and it works (setting status)
  3. change something, call twiggle_fit.fit() again, and it fails with the NaN exception
  4. twiggle_fit.status (and message at top of printout) still show success (as well as all other information from the last successful fit)

All state information in the fit should be refreshed according to the new fit attempt. Ideally this state information would be saved every time it's replaced (hint FitResult object) but at least it shouldn't be stale while showing 'success'.

Question: does this only happen when the fit ends in an exception?

...
re-optimizing vertical oscillation parameters...
starting fit...
Traceback (most recent call last):
  File "./pyfitter.py", line 255, in <module>
    twiggle_fit.fit()
  File "/home/james/recon_east/ratio/gm2ilratio/pymodules/util.py", line 2732, in fit
    **self.minimizer_kwargs
  File "/usr/local/lib/python2.7/dist-packages/lmfit/minimizer.py", line 2448, in minimize
    return fitter.minimize(method=method)
  File "/usr/local/lib/python2.7/dist-packages/lmfit/minimizer.py", line 2117, in minimize
    return function(**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/lmfit/minimizer.py", line 1503, in leastsq
    lsout = scipy_leastsq(self.__residual, variables, **lskws)
  File "/usr/local/lib/python2.7/dist-packages/scipy/optimize/minpack.py", line 394, in leastsq
    gtol, maxfev, epsfcn, factor, diag)
  File "/usr/local/lib/python2.7/dist-packages/lmfit/minimizer.py", line 548, in __residual
    nan_policy=self.nan_policy)
  File "/usr/local/lib/python2.7/dist-packages/lmfit/minimizer.py", line 2312, in _nan_policy
    raise ValueError(msg)
ValueError: NaN values detected in your input data or the output of your objective/model function - fitting algorithms cannot handle this! Please read https://lmfit.github.io/lmfit-py/faq.html#i-get-errors-from-nan-in-my-fit-what-can-i-do for more information.
>>> 
>>> print twiggle_fit
--------------------------------------------------------------------------
 Fit status: 3 (success)
 Both actual and predicted relative reductions in the sum of squares
   are at most 0.000000 and the relative error between two consecutive iterates is at 
   most 0.000000
   parameter   value          error       start          bounds
      N0       1.4914e+07  +- 1116        1.4713e+07    -inf,inf  
      A        0.37159     +- 2.165e-05   0.37238       -inf,inf  
      r        -13.235     +- 0.6569      0             -inf,inf  
    phi_a      2.0749      +- 0.0001106   2.0735        -inf,inf  
    tau_mu     64423       +- 1.353       64232         -inf,inf  
    A_cbo      -0.0028727  +- 3.446e-05   0.0023581     -inf,inf  
   tau_cbo     2e+05       - - - - - - - - FIXED - - - - - - - -
 omega_cbo_0   0.0023377   - - - - - - - - FIXED - - - - - - - -
  phi_cbo_0    2.4708      +- 0.01203     1.88          -inf,inf  
...

History

#1 Updated by James Stapleton about 1 year ago

James Stapleton wrote:

[...]

All state information in the fit should be refreshed according to the new fit attempt. Ideally this state information would be saved every time it's replaced (hint FitResult object) but at least it shouldn't be stale while showing 'success'.

Question: does this only happen when the fit ends in an exception?

[...]

LMFit state updates are applied on re-fit in the event of 1) optimizer success + error bars, 2) optimizer success without error bars, and 3) optimizer failure without exceptions. Part of this is done 'by hand' in LMFit/FitBase after the underlying fit code exits, meaning that member lmfit_params is updated before return to LMFit scope but not the others like params, initial_params, param_errors (others..?). So there could be bugs, because this is not a good way to manage state variables, but I haven't seen any others aside from the case of unhandled exceptions.

TODO: try that other fit parameters class in util.py, where I got it to work as both types of object (i.e. iterator on fit parameters loops over actual floating-point values instead of just their names) because then we could remove param_names/params_fixed(?)/initial_params, replace params tuple with that parameters class, and even eliminate lmfit_params. (Better to make any reference to a deprecated data member fail completely, to avoid 'uncaught' bugs in places where I may forget to update the code.)

Also available in: Atom PDF