Fix Confusing Custom Slit Resolution:

[butlerpd]

Background

The slit smear resolution function in SasView is designed for the “infinite slit” case of, for example, a Bonse Hart or Kratky camera. It assumes the resolution is essentially a “flat top” over a q range that is much larger than the maximum q of the data (typically an order of magnitude or more) in the direction perpendicular to the “scan” direction (the slit height) while being negligible in the direction parallel to the scan direction. A second order correction has been seen to be sometimes useful to account for a finite slit “width” compared to the slit height (see @ajj ). This should however be small. Note that this is how it is defined in the NXcanSAS standard as well.

Current SasView Status

SasView does not currently support resolution functions with non azimuthally symmetric components, and, in particular, does support the more complicated finite slits that some modern instruments are beginning to implement such as the NCNR VSANS. It also does not support non Gaussian resolutions even if azimuthally symmetric such as is often encountered on TOF instruments. Note that at this time the NXcanSAS format does not provide for these either though there is a canSAS effort to do so.

The Problem

There has been considerable confusion over the years as to what the SasView code does or should do witnessed by the use of qx and qy (leading to people confusing real space slit orientation in 2D with inverse space), q_radial and q_phi (not really correct except as it intersects the above definition), and q_parr and q_perp (correct if assuming parallel and perpendicular to the scan direction but not being defined is often confused with other things such as parallel and perpendicular to the q in 2D or parallel and perp to an alignment direction in real space)

More importantly, the users are not properly guided and can produce incorrect results by entering, for example, a large width vs height or entering a true rectangular resolution which is not appropriate. In the first case the result of course is a flat line Intensity vs Q corresponding to the average scattering intensity.

Solution

The situation would be significantly improved as follows (particularly points 1,3 and 4):

• [ ] capture user error when incorrectly providing a qwidth larger than qheight and
  • [ ] swap the two
  • [ ] provide a pop up error message to warn the user of the incorrect usage (refer them to the documentation) and the fact that the values have been swapped
• [ ] Ideally, check for rectangular apertures where q_height <10 q_width or q_height <qmax
  • [ ] convert to to a sqrt(q_width^2+q_height^2) and send to normal resolution function
  • [ ] pop up warning of what was done and why
• [ ] replace all nomenclature in the code of qx and qy, qradial an qphi etc with q_height and q_width
• [ ] Update the documentation
• [ ] As appropriate create a new issue to provide non azimuthally symmetric resolution correction in 2D

[smk78]

@butlerpd wrote:

• [ ] Update the documentation

Update the documentation and provide a tutorial of what to do and what to not do? :-)

[butlerpd]

It has recently been pointed out by several people that actually a large source of confusion comes from the height nomenclature which suggests a real space concept when in fact this is all about inverse space. Also, as evidenced by the canSAS discussions on resolution over the years and the final specification for the canSAS data formats, the proper nomenclature should be length so d_length (or dl) not d_height. Recommend we make this change part of this issue.

[toqduj]

TBH, I also find it confusing how smearing is input, for example that a q-dependent input smearing can be added to the data in units of percent for a given q, or as a Gaussian width. That probably makes sense for some SANS experiments, but not for SAXS experiments.

Ideally, I'd be able to use our actual beam profile on the detector as a smearing input kernel, rather than approximations to a Gaussian. Depending on our collimation settings, our beam shape can range from something peaky (Gaussian or Lognormal) to a trapezoidal function, and is not azimuthally symmetric (as we have square slits as opposed to round pinholes, as well as non-ideal optics leading to a different divergence in the horizontal vs. vertical plane). If actual beam profiles cannot be used, then at least let's enable the choice from a range of possible profiles for the horizontal and vertical plane, respectively...

Wavelength resolution is another thing.. but that's too far from my expertise for me to make any contribution to.

[smk78]

Ideally, I'd be able to use our actual beam profile on the detector as a smearing input kernel

If this was implemented presumably we could do away with the Slit Size Calculator tool?

[butlerpd]

Actually, as I understand it, this is really a different question altogether and one that is, I think, exactly what the canSAS resolution workshop was about: more complex resolutions? BTW, he idea of using beam profiles was contemplated 10 years ago or more, when it was SansView and of course for SANS that does not work so well because it only captures the divergence contribution to the resolution and not the contribution from wavelength spread which are significant for SANS. For SAXS instruments I would assume that is not true as the wavelength spread is usually negligible? 😃

Did you attend the workshop @toqduj? The main thing discussed as I recall was to use an array to describe the resolution which is probably the right thing to be able to generically handle all the possible profiles as you mention. On the other hand, as I recall the NXcanSAS specification also envisaged the possibility of defining non-Gaussian functional forms (like atrapezoidd?). However that, like other resolution forms, need to have definitions added so that producers and consumers of the data have an agreed way of interpreting/handling such data.

FYI @smk78, the Slit Size calculator, while using a beam profile for the calculation, is actually just providing the same slit resolution that is currently defined and does not provide any new functionality like what @toqduj is asking for

[butlerpd]

On another note, we need to move this discussions somewhere it can stay active as it is completely separate from the very limited scope of this ticket which is being actively worked on I believe by @pbeaucage. We should not lose this thread when the ticket is closed. I believe there is a ticket about using arrays for resolution that I'm sure @krzywon can point us too 😄 and at the workshop we agreed that SasView would provide a testing ground for solutions. Alternatively we could create a discussion ticket. The second seems more appropriate but also has the risk of being forgotten and then lost when the discussion dies down? Other thoughs?

[smk78]

Our wiki?

[toqduj]

alas, @butlerpd when the resolution workshop was going on, I was on the water trying to remember my starboard from my ports so I missed that event. In the end sure, if resolution can be described with an array for Qx, Qy, and another one for the wavelength resolution (which I always imagine to be in the Z direction even though it isn't), we can use trapezoids, schultz-zimms, Student T's or whatever we feel like, and even actual beam profiles for those of us blessed with (approximated) monochromaticity.

I think @smk78 is right that this would make the slit length calculator obsolete. That seems to be a functionality to approximate measured Kratky-camera length profiles to SasView slit length units.

[toqduj]

A 2D (or 2D + 1D for divergence+wavelength) smearing kernel in (Q, I) would need to be provided in principle. This can either be computed and added into the mix, or extracted from the NeXus file. The Q matrix for this smearing kernel could be different than the Q matrix for the scattering data itself, I think (unless that would make things too hard on the fast smearing front, @pkienzle?)

[pbeaucage]

Probably echoing many points above:

I think I would push back somewhat on putting too much physically-inspired custom resolution capability into a 1D or even 2D fitting package; to me, the various physical terms (divergence, wavelength distribution, sample thickness, ToF timing specifics, etc.) really belong in reduction, not in fitting... the interface between the two should be, in some form, just a description of the q distribution in a given point, whether by forcing an analytical distribution and storing/passing those parameters or by storing it explicitly. I would argue that forcing that distribution to geometry of a SAXS instrument is not the 'right' way to do that.

In some sense the existing slit smearing tool is vestigial; as I understand it the code was added years ago to support the Anton Paar SAXSess Kratky cameras which don't output dQ values in their default reduction pipeline. Given the age of the design and discontinuation of the instrument, in a couple years there will probably only be a handful of such instruments in the wild and we can gently scoot the generation of smearing kernels back into data reduction. (I believe that the other slit-smeared instruments remaining are essentially the Bonse-Hart USAXS at the APS and ESRF, handful of Rigaku lab Bonse-Harts, and the various USANS, all of which, I believe, generate dQ distribution widths in reduction).

Echoing @butlerpd, as I understand it, the scope of the current ticket is clarifying the assumptions and input parameters/rules of the existing slit smearing kernel in the GUI, code, and documentation. Full treatment of non-Gaussian smearing kernels is a different beast.

[toqduj]

Ok, for those interested, I opened a new issue #1865 to continue the discussion there.

[lucas-wilkins]

Ok, for those interested, I opened a new issue https://github.com/SasView/sasview/issues/1865 to continue the discussion there.

I have now closed #1865 to keep these discussions all in the same place.