Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#312 closed enhancement (fixed)

Problem with slit smearing

Reported by: butler Owned by:
Priority: major Milestone: SasView 3.1.0
Component: SasView Keywords:
Cc: Work Package: SasModels Redesign

Description

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.

Attachments (3)

comparison.pdf (22.3 KB) - added by butler 3 years ago.
comparison of IGOR vs SasView? slit smearing of ellipsoid model
IgorModel.txt (2.1 KB) - added by butler 3 years ago.
Igor generated slit smeared ellipsoid model data
slit_test.py (18.7 KB) - added by pkienzle 3 years ago.

Download all attachments as: .zip

Change History (10)

Changed 3 years ago by butler

comparison of IGOR vs SasView? slit smearing of ellipsoid model

Changed 3 years ago by butler

Igor generated slit smeared ellipsoid model data

comment:1 Changed 3 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 3.1

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 ½ 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.

comment:2 Changed 3 years ago by pkienzle

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.

Changed 3 years ago by pkienzle

comment:3 Changed 3 years ago by pkienzle

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.
  1. use sampling around each point to average over the oscillations
  1. use logarithmic rather than linear bin edges

These can be tried independently or together.

comment:4 Changed 3 years ago by butler

  • Priority changed from major to blocker

comment:5 Changed 3 years ago by pkienzle

  • Milestone changed from SasView 3.1 to SasView Next Release +1
  • Priority changed from blocker to major
  • Type changed from defect to enhancement
  • Work Package changed from SasView Bug Fixing to SasModels Redesign

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.

comment:6 Changed 2 years ago by pkienzle

  • Resolution set to fixed
  • Status changed from new to closed

comment:7 Changed 2 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 3.1.0
Note: See TracTickets for help on using tickets.