Problem with constrained simultaneous fit (Trac #441)

[butlerpd]

Identified by Ridchard Heenand during testing for 3.1 release

It is a bit worrisome that with a lot of testing there seemed to be some "erratic results" not always reproducilbe. Also the error reported in the first reporting of this issue (see below) does not seem to show up with this example (which Richard found to fail reproducibly). The question still is whether there is some faulty logic somewhere in the fitting or if the fit engine is not converging and sending back "garbage" that is causing fit to fail.

'''From Richard'''
Load attached project.

Set up constraints on all parameters, M2=M3, M1=M3, as per odd1a.jpg

Then go into each of the three fit pages and turn all parameters off, then select these four to be on: radius, thickness, volfraction and “distribution of radius”

In “const & simul fit” tab hit “fit”, then nothing at all happens! Individual fits on the Fitpage1, 2, 3 still work.

This can be “unlocked” by removing the constraints on all but the 4 actually adjusting parameters. (In other circumstance the constraints on non-adjusting parameters are working fine, as might be expected.) I suspect that the underlying logic is slightly adrift somewhere, but I’ve not got time today to start looking at the actual code.

It can also be unlocked by turning on all parameters and hitting fit, though the results are then of course unphysical.

Repeating the above set up of constraints on all 10 parameters, and then asking only 4 to adjust, also gets back to a “nothing happens” state.

Having constraints that work all the time is very useful, e.g. for a block copolymer I may want to say thickness=0.2*radius, regardless of whether radius is adjusting or not. I have some other constraints as used in FiSH to code up one day that are far more complicated.

---

Original message:
If I set up 3 data sets with constraints, say have M2.radius=M1.radius, M3.radius=M1.radius but then fix M1.radius at say 30 ang, I would expect the constraints to still work, but I get error message on hitting Fit in constraints page.

#!python
                Traceback (most recent call last):
  File "sas\perspectives\fitting\fit_thread.pyc", line 82, in compute
  File "sas\perspectives\fitting\fit_thread.pyc", line 14, in map_apply
  File "sas\perspectives\fitting\fit_thread.pyc", line 11, in map_getattr
  File "sas\fit\BumpsFitting.pyc", line 262, in fit
  File "sas\fit\BumpsFitting.pyc", line 345, in run_bumps
  File "bumps\fitters.pyc", line 859, in stderr
  File "bumps\lsqerror.pyc", line 79, in hessian
  File "bumps\numdifftools.pyc", line 1159, in __call__
  File "bumps\numdifftools.pyc", line 1170, in hessian
  File "bumps\numdifftools.pyc", line 1084, in hessdiag
  File "bumps\numdifftools.pyc", line 720, in _partial_der
  File "bumps\numdifftools.pyc", line 424, in _derivative
  File "bumps\numdifftools.pyc", line 686, in _romb_extrap
ValueError: operands could not be broadcast together with shapes (24,) (0,)
 
 None

OK the work around for this is to also fix M2.radius etc manually. However if I do that and then hit Fit on constraints page, nothing happens not even an error message. So if I “Remove” the constraints on M2.radius and M3.radius, “Fit” now attempts to work but comes back with same error message as above in red, presumably because it now has an issue with radius.width which is still constrained and fitting. Indeed if I remove the constraints on radius.width the fit now works, but with independent values for the polydispersity.

I would expect the constraints to work regardless of whether the base parameters in them are fixed or adjusting.

Meanwhile perhaps there can be a quick fix in this release to put up a message that “constrained parameters must all be adjusting” ?

If anyone wants a simple 3 contrast core/shell microemulsion project, with real SANS data, to test the above just ask. I am grateful that “Save project” does now actually save all 3 data sets and models. (It would be nice if it also remembered which parameters are on/off, and in the +1 release, saved the constraints also, so that a fully working project could be emailed to someone else, as setting up the constraints etc is still non-trivial.)

Migrated from http://trac.sasview.org/ticket/441

{
    "status": "new",
    "changetime": "2017-10-27T10:17:22",
    "_ts": "2017-10-27 10:17:22.679590+00:00",
    "description": "Identified by Ridchard Heenand during testing for 3.1 release\n\nIt is a bit worrisome that with a lot of testing there seemed to be some \"erratic results\" not always reproducilbe.  Also the error reported in the first reporting of this issue (see below) does not seem to show up with this example (which Richard found to fail reproducibly).  The question still is whether there is some faulty logic somewhere in the fitting or if the fit engine is not converging and sending back \"garbage\" that is causing fit to fail.\n\n'''From Richard'''\nLoad attached project.\n \nSet up constraints on all parameters, M2=M3, M1=M3, as per odd1a.jpg\n \nThen go into each of the three fit pages and turn all parameters off, then select these four to be on:  radius, thickness, volfraction and \u201cdistribution of radius\u201d\n \nIn \u201cconst & simul fit\u201d tab hit \u201cfit\u201d, then nothing at all happens!  Individual fits on the Fitpage1, 2, 3 still work.\n \nThis can be \u201cunlocked\u201d by removing the constraints on all but the 4 actually adjusting parameters. (In other circumstance the constraints on non-adjusting parameters are working fine, as might be expected.) I suspect that the underlying logic is slightly adrift somewhere, but I\u2019ve not got time today to start looking at the actual code.\n \nIt can also be unlocked by turning on all parameters and hitting fit, though the results are then of course unphysical.\n \nRepeating the above set up of constraints on all 10 parameters, and then asking only 4 to adjust, also gets back to a \u201cnothing happens\u201d state.\n \nHaving constraints that work all the time is very useful, e.g. for a block copolymer  I may want to say thickness=0.2*radius, regardless of whether radius is adjusting or not. I have some other constraints as used in FiSH to code up one day that are far more complicated.\n\n--------\nOriginal message:\nIf I set up 3 data sets with constraints, say have M2.radius=M1.radius, M3.radius=M1.radius but then fix M1.radius at say 30 ang, I would expect the constraints to still work, but I get error message on hitting Fit in constraints page. \n{{{ \n#!python\n                Traceback (most recent call last):\n  File \"sas\\perspectives\\fitting\\fit_thread.pyc\", line 82, in compute\n  File \"sas\\perspectives\\fitting\\fit_thread.pyc\", line 14, in map_apply\n  File \"sas\\perspectives\\fitting\\fit_thread.pyc\", line 11, in map_getattr\n  File \"sas\\fit\\BumpsFitting.pyc\", line 262, in fit\n  File \"sas\\fit\\BumpsFitting.pyc\", line 345, in run_bumps\n  File \"bumps\\fitters.pyc\", line 859, in stderr\n  File \"bumps\\lsqerror.pyc\", line 79, in hessian\n  File \"bumps\\numdifftools.pyc\", line 1159, in __call__\n  File \"bumps\\numdifftools.pyc\", line 1170, in hessian\n  File \"bumps\\numdifftools.pyc\", line 1084, in hessdiag\n  File \"bumps\\numdifftools.pyc\", line 720, in _partial_der\n  File \"bumps\\numdifftools.pyc\", line 424, in _derivative\n  File \"bumps\\numdifftools.pyc\", line 686, in _romb_extrap\nValueError: operands could not be broadcast together with shapes (24,) (0,)\n \n None\n}}} \n  OK the work around for this is to also fix M2.radius etc manually. However if I do that and then hit Fit on constraints page, nothing happens not even an error message. So if I \u201cRemove\u201d the constraints on M2.radius and M3.radius, \u201cFit\u201d now attempts to work but comes back with same error message as above in red, presumably because it now has an issue with radius.width which is still constrained and fitting. Indeed if I remove the constraints on radius.width the fit now works, but with independent values for the polydispersity.\n\n  I would expect the constraints to work regardless of whether the base parameters in them are fixed or adjusting.\n\n  Meanwhile perhaps there can be a quick fix in this release to put up a message that \u201cconstrained parameters must all be adjusting\u201d ?\n\n  If anyone wants a simple 3 contrast core/shell microemulsion project, with real SANS data, to test the above just ask. I am grateful that \u201cSave project\u201d does now actually save all 3 data sets and models. (It would be nice if it also remembered which parameters are on/off, and in the +1 release, saved the constraints also, so that a fully working project could be emailed to someone else, as setting up the constraints etc is still non-trivial.)\n",
    "reporter": "butler",
    "cc": "",
    "resolution": "",
    "workpackage": "SasView Bug Fixing",
    "time": "2015-06-30T17:50:43",
    "component": "SasView",
    "summary": "Problem with constrained simultaneous fit",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView 4.3.0",
    "owner": "",
    "type": "defect"
}

[butlerpd]

Trac update at 2015/06/30 17:51:22:

• butler changed attachment from "" to "Microemul_11_sasview_proj_fit_simult.svs"
• butler commented:

project file to use for test

[butlerpd]

Trac update at 2015/06/30 17:51:48:

• butler changed attachment from "" to "odd1a.jpg"
• butler commented:

screen shot

[butlerpd]

Trac update at 2017/10/27 10:17:22: butler changed milestone from "SasView Next Release +1" to "SasView 4.3.0"

[RichardHeenan]

Closing this as out of date now, needs more recent tests of sasview.....