Opened 6 years ago

Closed 6 years ago

#1072 closed defect (fixed)

Orientation distributions seem to depend on initial angle

Reported by: smk78 Owned by:
Priority: blocker Milestone: SasView 4.2.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing


Reported by Patrick Corona.

The perfectly oriented calculations (i.e. no orientation distributions) now match what we were calculating. Also, importing data for fitting works for us, and we are excited by the potential this offers to compare and fit to models of oriented structures.

We do run into some issues as we begin to apply orientation distributions that I will highlight with the ‘stock’ spectra prediction calculator. As we apply orientation distributions with the array utility, the results tend to depend on the initial angle one sets, even for a uniform distribution.

For example, if I apply the uniform distribution (attached as uniform.txt) to the parallelepiped model in both theta and psi directions (i.e. equivalent weighting to all out of plane and c-axis rotation angles with one in-plane direction evaluated) the results do not match our predictions for what a parallelepiped oriented at 60 deg in plane should look like (Note: length and scale parameters are just what are provided initially for the model):


If I change the theta and psi angles – which I would not expect would change anything because I have imported a custom distribution – I can get some drastic changes to the spectra, eventually leading to a similar spectra to what we have predicted with our own code:


Our initial hypothesis was that changing these angles changes the initial angle the distribution is evaluated at, but this doesn’t make sense for the uniform distribution we are testing here. Have we set up the array wrong? I’ve also tried an array that runs from 0 to 360 degrees, but that doesn’t change anything. Additionally, the results get more confusing with non-uniform distributions, and I will not go into details on those unless it can be helpful to solving this problem – I think that fixing whatever is causing this will fix those problems we are having too.

Let me know if I can provide more information from what we have been seeing with the non-uniform distributions (if the solution is not obvious).

Attachments (3)

uniform.txt (228 bytes) - added by smk78 6 years ago.
Uniform distribution
corona-fig-1.png (314.4 KB) - added by smk78 6 years ago.
Corona Fig1
corona-fig-2.png (289.9 KB) - added by smk78 6 years ago.
Corona Fig2

Download all attachments as: .zip

Change History (6)

Changed 6 years ago by smk78

Uniform distribution

Changed 6 years ago by smk78

Corona Fig1

Changed 6 years ago by smk78

Corona Fig2

comment:1 Changed 6 years ago by smk78

Also see related orientation tickets:

comment:2 Changed 6 years ago by butler

  • Milestone changed from SasView 4.3.0 to SasView 4.2.0
  • Priority changed from major to blocker

This may be a case of misunderstanding of the documentation. Given that the major update for this release is fixing the orientational distribution this tickets needs to be resolved before releasing. It could be an error in the code or an error in understanding. In the latter case the documentation should be looked at since this is one of the expert groups in shear SANS and oriented SANS. If they are confused it is not clear that any user will be able to figure it out?

comment:3 Changed 6 years ago by butler

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

The original worry I believe has been resolved, including fixing a problem with the builtin uniform distribution. The group now agrees with the orientation definition and rotation matrix and they get the same results from their code for cases with no orientational distribution.

The problem now is validating the orientational distribution which is a much harder tasks since the current typical way this is done seems to be through an order parameter defined in the plane of the detector whereas SasView is trying to go a step (or two) further and bring real physical insights by using the real 3D object and defining an orientational distribution in the frame of the object and then projecting that onto the plane of the detector. I am thus going to close this out and open a new ticket to validate the orientational distribution.

Note: See TracTickets for help on using tickets.