Opened 8 years ago

Closed 5 years ago

#492 closed enhancement (obsolete)

choice of parameterization of orientation angles

Reported by: butler Owned by: butler
Priority: major Milestone: SasView 4.2.0
Component: SasView Keywords:
Cc: Work Package: SasModels Infrastructure

Description (last modified by butler)

The current orientation angles, while they seem to be correct, are not natural for the user.
For the cylinder, it would be preferable if theta were the angle of the cylinder axis with respect to the beam, with 0 corresponding to a cylinder along the beam, and a circular scattering pattern, and 90 corresponding to a cylinder perpendicular to the beam. This corresponds to latitude. The angle phi ranging from -180 to 180 would rotate the cylinder in a circle of constant angle theta, corresponding to longitude.
This would allow users to set phi by inspection since it would be mostly independent of theta. It would also allow for faster phi polydispersity since a fixed 2D image could be used without having to recompute it for each phi, much like we will (eventually) be doing for 2D resolution

This would require redoing the model maths and needs broader agreement than just "fixing"

Change History (10)

comment:1 follow-up: Changed 8 years ago by pkienzle

The current orientation angles, while the seem to be correct, are not natural for the user.

For the cylinder, it would be preferable if theta were the angle of the cylinder axis with respect to the beam, with 0 corresponding to a cylinder along the beam, and a circular scattering pattern, and 90 corresponding to a cylinder perpendicular to the beam. This corresponds to latitude. The angle phi ranging from -180 to 180 would rotate the cylinder in a circle of constant angle theta, corresponding to longitude.

This would allow users to set phi by inspection since it would be mostly independent of theta. It would also allow for faster phi polydispersity since a fixed 2D image could be used without having to recompute it for each phi, much like we will (eventually) be doing for 2D resolution.

comment:2 Changed 8 years ago by butler

  • Owner set to richardh
  • Status changed from new to assigned

comment:3 Changed 8 years ago by butler

  • Description modified (diff)
  • Owner changed from richardh to butler
  • Priority changed from blocker to critical
  • Summary changed from check orientation angles to choice of parameterization of orientation angles
  • Type changed from defect to enhancement
  • Work Package changed from SasView QA and testing to SasModels Redesign

comment:4 Changed 8 years ago by butler

  • Milestone changed from SasView 4.0.0 to SasView Next Release +1
  • Priority changed from critical to major

comment:5 Changed 7 years ago by pkienzle

Regarding angular dispersity, I had some discussions with a user measuring oriented samples and a theorist simulating disorder in orientation. We concluded that something like the following would be useful:

Given the orientation vector along the axis of the shape as described above, define axial dispersity as a perturbation of this axis. In the isotropic case, the dispersity weight w(x) represents the probability that the shape axis will be found at angle x with respect to the orientation direction, in any direction. For anisotropic dispersity there will be a soft axis with larger dispersity and a perpendicular hard axis with smaller dispersity. For non-rotationally symmetric particles, the rotation vector psi is likely aligned with the hard or the soft axis. There will be a separate rotational dispersity associated directly with psi. For rotationally symmetric particles, any orientational anisotropy will depend on the flow field which defined the alignment, which could be in any direction.

Translating this to SasView is a bit challenging. We could use latitude, longitude and rotation as the names of the orientation parameters. The usual rotation.width will work for rotational dispersity. Unfortunately, neither latitude.width nor longitude.width is directly tied to the hard and soft axes of the orientation dispersity. We could define latitude.width as expected, and define longitude.width as the distance along the great circle perpendicular to longitude from the given latitude. One of these is the hard axis and the other the soft axis, so all we need is another parameter to which rotates the resulting points about the orientation direction. It would be convenient if the definition we chose happened to align with the shear direction relative to the beam in shear flow experiments with the soft axis in the direction of the flow and the hard axis perpendicular to the flow.

The above definitions should work for strongly oriented samples using gaussian dispersion, which is the majority of the cases we are trying to cover.

Particle orientation can be bimodal. For example, in particles with a thick end and thin end, the thick end or the thin end may be oriented with the shear direction (with a preference for one over the the other) but very few particles will be oriented across the shear. For strongly oriented samples, such systems could be handled with the sum of two models with orientations 180 degrees apart.

Weakly oriented systems will not be well described by our existing distributions. If particles can shift as much as 90 degrees, then they are probably isotropic in that direction (including rotation about the axis). None of our distributions will exhibit this sort of behaviour. We may want to set a default maximum on the angular dispersion at 30 degrees or less, with strong warnings in the manual that we don't understand weakly oriented systems, and the simulations may not be meaningful.

It would be useful to check that our definition supports unoriented samples, ideally defining them as a rectangular distribution of width ±90 for latitude and longitude [NOT the gaussian equivalent rectangular width as defined in SasView!], with whatever corrections are needed for the polar coordinates integration to produce the right answer. This exercise will provide hints regarding how to interpret weakly oriented samples which are not fully isotropic.

The internal implementation of polydispersity will not support the above definition. Currently we send in a set of values to evaluate for each parameter, but the definition about requires a non-linear transformation that depends on the orientation angle. Rather than centering and scaling in the distribution definition, we could send the distribution (x, w(x)) centered at 0, adding the polydispersity to the parameter value each time through the loop rather than replacing it. The distribution truncation code, which allows us to limit parameters to the min-max range will need to take this into account. Setting limits on orientation parameters should not affect the angular distribution, unlike the polydispersity on shape parameters.

We need to be careful about limits on the angles for the orientation. If they are unlimited, DREAM will happily find multiples of 360 that fit equally well. If longitude is limited to [-180, 180] and the optimal value is near 180, then DREAM will not be able to identify the proper uncertainty distribution because it will be limited to 180. In this case, the fit should be redone with limits in the range [0, 360]. There will be strange effects for latitude 90, since 91 degrees is practically equivalent to 89 degrees in the above definition. Not sure how to handle this case.

comment:6 in reply to: ↑ 1 ; follow-up: Changed 7 years ago by dirk

Replying to pkienzle:

The current orientation angles, while the seem to be correct, are not natural for the user.

For the cylinder, it would be preferable if theta were the angle of the cylinder axis with respect to the beam, with 0 corresponding to a cylinder along the beam, and a circular scattering pattern, and 90 corresponding to a cylinder perpendicular to the beam. This corresponds to latitude. The angle phi ranging from -180 to 180 would rotate the cylinder in a circle of constant angle theta, corresponding to longitude.

This would allow users to set phi by inspection since it would be mostly independent of theta. It would also allow for faster phi polydispersity since a fixed 2D image could be used without having to recompute it for each phi, much like we will (eventually) be doing for 2D resolution.

Please also check that averaging over the orientational distribution works correctly. I did some tests with the 2D cylinder model and I have the impression that the orientation average over the orientation distribution is not calculated correctly. There is a spherical_correction in kernel_iq, which should do the job, but right now it is bugged. The correction should be done over the polar angle (right now called) alpha between the cylinder axis with respect to the beam. In the 1D average, it is done correctly. This issue will be fixed automatically together with this ticket, when theta is choosen as the lattitude of the cylinder axis with respect to the beam. With this redefinition of theta, no further changes deep in the code have to be done.

comment:7 in reply to: ↑ 6 Changed 7 years ago by pkienzle

Replying to dirk:

Replying to pkienzle:

The current orientation angles, while the seem to be correct, are not natural for the user.

For the cylinder, it would be preferable if theta were the angle of the cylinder axis with respect to the beam, with 0 corresponding to a cylinder along the beam, and a circular scattering pattern, and 90 corresponding to a cylinder perpendicular to the beam. This corresponds to latitude. The angle phi ranging from -180 to 180 would rotate the cylinder in a circle of constant angle theta, corresponding to longitude.

This would allow users to set phi by inspection since it would be mostly independent of theta. It would also allow for faster phi polydispersity since a fixed 2D image could be used without having to recompute it for each phi, much like we will (eventually) be doing for 2D resolution.

Please also check that averaging over the orientational distribution works correctly. I did some tests with the 2D cylinder model and I have the impression that the orientation average over the orientation distribution is not calculated correctly. There is a spherical_correction in kernel_iq, which should do the job, but right now it is bugged. The correction should be done over the polar angle (right now called) alpha between the cylinder axis with respect to the beam. In the 1D average, it is done correctly. This issue will be fixed automatically together with this ticket, when theta is choosen as the lattitude of the cylinder axis with respect to the beam. With this redefinition of theta, no further changes deep in the code have to be done.

In the current code, choosing a rectangular distribution phi with width 180/sqrt(3) and theta with width 90/sqrt(3) for sigma=1 and limits -360,360 and setting theta=phi=0 gives the correct sum in the current model. when theta goes off zero, then the symmetric interval around theta no longer goes from pole to pole, and the polar values are overemphasized. This problem will not exist for the new proposal, which always treats the orientation axis and thus is independent of latitude and longitude.

comment:8 Changed 7 years ago by dirk

I have the impression this is a bigger issue. This ticket will be resolved for cylinder, core_shell-cylinder, core_shell_ellipsoid, core_shell_bicelle, hollow_clinder, ellipsoid, capped_cylinder, barbell model where the rewriting on sherical coordinates is done. For the other models and still open questions I will open new specific tickets to split the task in doable subunits.

comment:9 Changed 7 years ago by dirk

In 0d6e86566d51a1fba22933bdbac8c40d36f9bd76/sasmodels:

Rewriting selected models in spherical coordinates. This fixes ticket #492 for these models.

comment:10 Changed 5 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 4.2.0
  • Resolution set to obsolete
  • Status changed from assigned to closed
  • Work Package changed from SasModels Redesign to SasModels Infrastructure

I am going to close this as obsolete since the new orientational infrastructure has been deployed. There is still plenty of testing and new use cases to explore but those will be new tickets as appropriate.

Note: See TracTickets for help on using tickets.