Problem with slit smearing (Trac #312)

[butlerpd]

Reported by Matthew Wasbrough:

I have been playing with the beta of sasview, although this problem is also on the release version. If you create a model data set in Igor using the Uniform_Ellipsoid model then recreate the model in sasview using the EllipsoidModel, and using a custom slit smear in sasview of 0.117 the two models do not line up. I believe this is something in sasview and the way it calculates smearing.

This was something I found while at NIST and think I told you about, however getting Bumps running was more of a focus at the time. I wanted to make sure this was documented and you knew about it.

I have attached a test data set from Igor using the following parameters
background: 0
radius_a: 500
radius_b: 15000
scale: 0.05
sldEll: 1e-6
sldSolv: 6e-6

I also attach a pdf of the plot from sasview of the comparison between the two data sets.

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

{
    "status": "closed",
    "changetime": "2015-11-22T01:23:03",
    "_ts": "2015-11-22 01:23:03.791815+00:00",
    "description": "Reported by Matthew Wasbrough:\n\nI have been playing with the beta of sasview, although this problem is also on the release version. If you create a model data set in Igor using the Uniform_Ellipsoid model then recreate the model in sasview using the EllipsoidModel, and using a custom slit smear in sasview of 0.117 the two models do not line up. I believe this is something in sasview and the way it calculates smearing. \n\nThis was something I found while at NIST and think I told you about, however getting Bumps running was more of a focus at the time. I wanted to make sure this was documented and you knew about it.\n\nI have attached a test data set from Igor using the following parameters\nbackground: 0\nradius_a: 500\nradius_b: 15000\nscale: 0.05\nsldEll: 1e-6\nsldSolv: 6e-6\n\nI also attach a pdf of the plot from sasview of the comparison between the two data sets.\n",
    "reporter": "butler",
    "cc": "",
    "resolution": "fixed",
    "workpackage": "SasModels Redesign",
    "time": "2015-02-13T23:17:18",
    "component": "SasView",
    "summary": "Problem with slit smearing",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView 3.1.0",
    "owner": "",
    "type": "enhancement"
}

[butlerpd]

Trac update at 2015/02/13 23:18:14:

• butler changed attachment from "" to "comparison.pdf"
• butler commented:

comparison of IGOR vs SasView slit smearing of ellipsoid model

[butlerpd]

Trac update at 2015/02/13 23:19:00:

• butler changed attachment from "" to "IgorModel.txt"
• butler commented:

Igor generated slit smeared ellipsoid model data

[butlerpd]

Trac update at 2015/03/22 22:46:46:

• butler commented:

Paul Kienzle has identified a real problem. Somewhere along the line someone must have not understood something and removed the code tha extends the model far enough beyond the last data point to be able to properly compute the smeared value a that point. for slit smearing this is of course HUGE leading to the high q data (up to 1/2 of the data in fact depending on the model) of slit smeared data to be incorectely modeled. This should probably be addressed to zeroth order before a release.

• butler changed milestone from "SasView Next Release +1" to "SasView 3.1"

[pkienzle]

Trac update at 2015/03/23 14:41:52: pkienzle commented:

I compared both Igor and sasview to a direct implementation of the slit smearing integral using adaptive integration. Although neither is correct, the Igor implementation is much closer.

Looking at the code in sasview, I do not see where the residual term is added. This is the power law approximation to the tail of the distribution from q_max to q_max + Delta q_vertical. Maybe that is enough to explain the difference.

I implemented replacement resolution functions in sasmodels, though I do not yet use them in the fit. The basic idea is to continue to use a weight matrix, but allow it to be non-square, with calculated q values extrapolated to the full range of the resolution function. At least for the test problem (spheres of 6 micro radius), rectangular integration gets with 2.5% relative error for about the same number of evaluations. Trapezoid and Simpson’s rule don’t do any better.

The attached file (slit_test.py) will let you explore the various implementations. It contains a python implementation of the sphere model so that it depends only on scipy, numpy and matplotlib.

[pkienzle]

Trac update at 2015/03/23 14:42:31: pkienzle changed attachment from "" to "slit_test.py"

[pkienzle]

Trac update at 2015/03/23 22:05:19: pkienzle commented:

Made slit_test.py into a GIST so that we can edit it.

https://gist.github.com/pkienzle/2faa18591b7d82d4d62d

Things to try:

1. use power law interpolation between points rather than linear interpolation.

2. use sampling around each point to average over the oscillations

3. use logarithmic rather than linear bin edges

These can be tried independently or together.

[butlerpd]

Trac update at 2015/03/24 14:29:34: butler changed priority from "major" to "blocker"

[pkienzle]

Trac update at 2015/03/24 20:40:40:

• pkienzle commented:

The gross error has been removed from sasview, but we should still be able to do better with some of the ideas above. Moving the ticket to sasmodels for the next release.

• pkienzle changed milestone from "SasView 3.1" to "SasView Next Release +1"
• pkienzle changed priority from "blocker" to "major"
• pkienzle changed type from "defect" to "enhancement"
• pkienzle changed workpackage from "SasView Bug Fixing" to "SasModels Redesign"

[pkienzle]

Trac update at 2015/11/16 16:16:15:

• pkienzle changed resolution from "" to "fixed"
• pkienzle changed status from "new" to "closed"

[butlerpd]

Trac update at 2015/11/22 01:23:03: butler changed milestone from "SasView Next Release +1" to "SasView 3.1.0"