-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The current refactor branch envisages three data types in dataset-types. As discussed during the the XIV contributor camp, there is a strong argument to be made for only two data types: Full Q (3D) and simple Q (1D)... or some other appropriate nomenclature.
The thinking goes something like this. Start with the full Q vector in full 3D Q space. ALL data collected currently as far as we know is in such a space. The "2D" data is a partial spherical cut through that space, so all "2D" data should include all three Q components in a cartesian coordinate system defined relative to the incoming beam (incoming wave vector). It is possible, though extremely unlikely, that all the data in a "2D" data pattern are taken at (Qxi, Qyj, 0) but that is still in 3D. it just happens that all vectors probed are in a plane where Qz=0. Much more often it will be the case that Qz is "ignored" and bound up in the reported Qx and Qy. It is not clear why there should be a separate type for this.
While so called "1D data" remains the most common, it is achieved by making an important assumption: the scattering is azimuthally symmetric. That is that the intensity anywhere on a sphere of radius Q (in Q space) is identical. In this case, for simplicity, that space is then "collapsed" into 1D by integrating over every sphere of radius Qi providing a value as a function of said Qi (or magnitude of the Q vector). Thus it is no longer cut in 3D space but a collapsed space that probably does warrant its own type.
NOTE: there is some discussion about Qz, mainly how to represent it in a sasview repo issue (issue#3727) which should probably be moved to a discussion. It may be appropriate to move this to a discussion - possibly as part of the above?