Z-Space (SESANS) Fitting Perspective - A sketch

[lucas-wilkins]

Basic plan: Make a fitting perspective

1. Separate out the main fitting functionality from q-space fitting specific preparation steps and the post-processing (i.e. smearing)
2. Create a parallel perspective for Z-space fitting, that works with a slightly different pipeline, with the real space transforms explicitly added as a post-processing step
3. Set up data classes in a way that easily distinguishes between Z and Q space.
4. Define plot functionality spectific to these techniques (this is already done to some extent).
5. Add GUI elements specific to SESANS and other correlation space techniques.

Data processing refactored like this:

flowchart LR
A[Q Space Pre Processing] --> B{Fitting Core}
B --> C[Q Space Post Processing]
D[Z Space Pre Processing] --> E{Fitting Core}
E --> F[Z Space Post Processing]

Loading

[butlerpd]

How would simultaneous constrained fitting work between a SANS (higher Q, shorter L) and SESANS data (lower Q, higher L)? One of the reasons I thought that it was kept in the same perspective?

Another crazy thought I had while driving the other day was that since we treat the transform as a resolution, could we not just add it as an option in the resolution panel? This would be automatically populated when reading sesans data just like it is from any data file, but would then also "automatically" allow sesans theory to be calculated. Not sure however based on the work by @caitwolf if this doesn't raise a host of other problems?

[lucas-wilkins]

How would simultaneous constrained fitting work between a SANS (higher

Q, shorter L) and SESANS data (lower Q, higher L)? One of the reasons I thought that it was kept in the same perspective? Good point. I was discussing this today re. SEMSANS. There is something there, doesn't mean that the underlying architecture won't benefit from these changes, but the GUI side needs some thought. Maybe some way of organising model outputs and fitting differently (this would mean revisiting the "send" "functionality")

Another crazy thought I had while driving the other day was that since we

treat the transform as a resolution, could we not just add it as an option in the resolution panel? You mean to double down on the hackiness? I'm not convinced. There is definitely a difference between transforms and smearing, it doesn't help anyone to conflate the two. Then again, they're both what you could call "output modifiers" and it might make sense to have a specific section that you use for them. It would be possible to make something user friendly that allowed one to pick and choose what happens between the model calculation and the fit. SESANS fitting also modifies the input to the model, which is something that needs to be accounted for, it's not just the """smearing""" bit.

…

On Mon, Nov 7, 2022 at 4:07 PM Paul Butler ***@***.***> wrote: How would simultaneous constrained fitting work between a SANS (higher Q, shorter L) and SESANS data (lower Q, higher L)? One of the reasons I thought that it was kept in the same perspective? Another crazy thought I had while driving the other day was that since we treat the transform as a resolution, could we not just add it as an option in the resolution panel? This would be automatically populated when reading sesans data just like it is from any data file, but would then also "automatically" allow sesans theory to be calculated. Not sure however based on the work by @caitwolf <https://github.com/caitwolf> if this doesn't raise a host of other problems? — Reply to this email directly, view it on GitHub <#2375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKU4SXNYRLZMTP2OC6TWVLWHESNJANCNFSM6AAAAAARZJQZCI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Dr Lucas Wilkins +44 (0) 7505 915 726 Personal Website: http://www.lucaswilkins.com/ Alternate e-mail: ***@***.***

[butlerpd]

SESANS fitting also modifies the input to the model, which is something that needs to be accounted for, it's not just the """smearing""" bit.

Ahh ... good point. I did not realize there was front end bits as well. As for doubling down on "hackiness" LOL ... didn't think of it that way but fair point. Was more wondering whether there was a way of making the current approach less "hacky" I guess. Presumably we went down this path partly because it was the quickest at the time but presumably also because they was something in the idea that the concepts were close enough that with some thought once could simplify things? But yes, I am in way over my head and just throwing out "crazy thoughts" at the moment.

[pkienzle]

Consider that you ought to be able to calculate SESANS from the generic scattering calculator. Treating it as a property of the data rather than the model makes it easier to use it for different kinds of sample representation.

See also #2256.

[rmdalgliesh]

There are numerous issues to deal with no matter which way we look at this. Simultaneous fitting of SANS, SESANS, SEMSANS data is something that we should be aiming for given the way that many groups tend to approach the technique.

Our experience is, I guess, broadly similar to the approach to USANS. i.e. SANS data is collected and there is no particular turn over at low so groups want to determine if there is some sort of saturating length scale in the system and ask for time. Simulation of the data is becoming increasingly useful in this regard. Having a more accessible route to simulation is really important for this.
Then.. if the samples do produce a sensible signal the error bars in SESANS tend to be larger than SANS so having both data sets to co-refine a model becomes very important.

I would certainly like to see the ability to define a model and simulate the signal without the requirement to go through the importing of a data file. However, at the same time there is the need to define sensible defaults for the characteristics of the instrument that it would also be a good idea to model. For instance...
The Delft machine measures at ~2Å and as a consequence struggles to measure weakly depolarising samples in a sensible time. On the other hand Larmor at ISIS can use long wavelengths and quite often struggle to measure large length scales which strongly depolarise the beam.
Being able to model and plot the wavelength dependent depolarisation of the sample would be very beneficial for experiment simulation.
This might point you towards the possibility of reading in an instrument description file as part of the simulation that could be provided by the facilities.
In terms of the underlying data structures currently used, this wouldn't mean a huge amount of change. It would define the spin-echo length scale, the wavelength band and the detector acceptance. All of which are currently defined by the .ses file.

Given how little I currently understand about the SASView underlying architecture I may well be barking up the wrong tree but isn't this a similar problem to trying co-refine models for data taken with e.g. x-rays and neutrons or on different instruments with different resolution functions.

Rob