SESANS theories require data to initialise

[lucas-wilkins]

When making theoretical models for SESANS, it is necessary to load a data file. This appears to be an issue with initialisation, but requires some investigation.

[smk78]

It is probably unfair to call this a Defect. :-) The issue is that SasView grew up as an application for inverse-space (ie, Q) data analysis. SESANS data is in real-space. Thus one needs a way to 'tell' SasView that it is fitting real-space data.

Addressing this issue will touch on matters raised in several other issues under the SESANS label.

[wimbouwman]

I is indeed unfair to call it a defect. In Delft we use the theoretical models for SESANS frequently with students. It is no problem for them to load first a data-file.

[lucas-wilkins]

@smk78 @wimbouwman What I'm hearing is that (1) there are historical reasons why it is like it is, and (2) the workaround is easy. I'm not hearing that it is the way that it should be.

[butlerpd]

Definitely not "the way it should be" IMO. modeling is deliberately "a thing" so probably good to be able to do it in sesans as well as sans space ... though that may come back to bite us if we start adding DLS, NSE, ... infer sans? 😄 still probably the right thing?

[smk78]

Agreed. Not ideal. But the question is whether doing something to address this is a worthwhile use of resources in the context of other things? I'd argue some of the other SESANS issues are more serious, like the plots not updating when you change parameters, or not being able to use an S(Q) properly in a SESANS model! I think what we have here is another discussion item, isn't it, how to handle Q and non-Q modelling?

[butlerpd]

Priorities is another question altogether 😄

[lucas-wilkins]

It's pretty hard to build a picture of what needs changing and what resources said change will require if there's not a catalogue of the behaviours that need to be changed.

[smk78]

When SasView initialises it assumes that any data read, or any model to be calculated, is Q-space. Where it is reading data, in a suitable self-describing format, there is an obvious route to changing this behaviour (assuming the data is correctly described) and I think @krzywon has been going part way down this road in some of his branches. Note that at present the only thing telling SasView that some input data is SESANS is the file descriptor, not the data itself. But where you are just wanting to compute a model in real-space it is less clear how to proceed. There are probably several options. And those options mustn't make life a pain for those using SasView for 'traditional' Q-space fitting (ie, the core User community - no offence intended SESANS people!). Maybe there is a potential role here for the proposed Preferences dialog? But as @butlerpd & I have alluded too, if we're going to widen the range of data that SasView 'recognises' then there are other types too (eg, DLS & NSE with time bases instead of Q). Also, not all models will be applicable all of the time. So do we then add something to model descriptions to identify their validity? What then happens with backwards compatibility?

[krzywon]

Currently, there is a flag in the Data1D and Data2D objects called isSesans. sasmodels checks this flag and other items in the data to determine the type of resolution and if any transforms are required. To do what we want here, and to keep it extensible for future analysis methods like DLS and NSE, adding a combo box with different analysis types (SAS and SESANS currently) would work. If no data is sent to the fit window, the user would be free to select the type of analysis desired. If data is present, the type should be auto-selected based on the data and locked.

In my draft PR SasView/sasdata#28, I have different classes for different data types; SESANS, SlitSmeared1D, Pinhole1D, Pinhole2D, etc. This will make the selection process easier on the sasmodels end.

[lucas-wilkins]

Different subclasses for different kinds of data sounds good