improve structure factor calculations with beta approximation (Trac #1096)

[pkienzle]

Separate calculation of F so we can return <F> and <F*F> from the I(q) calculator. These will be used for an improved structure factor calculation with non-spherical particles. The average <.> is over size dispersity and orientation.

Migrated from http://trac.sasview.org/ticket/1096

{
    "status": "new",
    "changetime": "2018-10-30T22:44:25",
    "_ts": "2018-10-30 22:44:25.746505+00:00",
    "description": "Separate calculation of {{{F}}} so we can return {{{<F>}}} and {{{<F*F>}}} from the {{{I(q)}}} calculator.  These will be used for an improved structure factor calculation with non-spherical particles.  The average {{{<.>}}} is over size dispersity and orientation.  ",
    "reporter": "pkienzle",
    "cc": "",
    "resolution": "",
    "workpackage": "Beta Approximation Project",
    "time": "2018-04-18T15:08:39",
    "component": "sasmodels",
    "summary": "improve structure factor calculations with beta approximation",
    "priority": "major",
    "keywords": "",
    "milestone": "sasmodels Next Release +1",
    "owner": "",
    "type": "defect"
}

[RichardHeenan]

Trac update at 2018/05/18 15:09:19: richardh commented:

The "beta(Q)" correction or adjustment to S(Q) is needed for any polydisperse particles (including spheres) and any monodipserse (or indeed polydisperse) non-spherical particle. The most useful reference is M.Kotlarchyk & S-H Chen, J.Chem.Phys 79(1983)2461-2469. Ask Richard if you would like a copy.

Their equations (14) & (15) replace the original S(Q) by S'(Q) = 1 + beta(Q)( S(Q) -1) where

beta(Q) = ./<F.F>  tends to "damp out" the oscillations in S(Q).

will only be needed in addition to the usual <F.F> if an S(Q) is involved, so we will need a flag to show this.

Note that as usual we will have to be careful with where the scaling to get P(Q) is included, the Np.(Del rho)!^2, number of particles per unit volume times scattering contrast in P(Q) will cancel in beta(Q).

Note some subtle differences in convention as to what is included in P(Q) depending on authors and what is convenient, in Kotlarchyk & Chen P(Q) is per particle.

It may also be the case for various reasons that users want to turn the beta(Q) term on/off so we will need controls to do this.

Users will also want to save beta(Q) along with at least S'(Q) and perhaps the original S(Q), so we ought somehow to make clear in sasview whether a given "S(Q)" work space includes the beta(Q) correction or not.

Note that this is all still within the "decoupling approximation" that the sizes and/or orientations of particles are totally uncorrelated with their positions.

In the real world this is no longer true as concentration increases if particles are say very polydisperse (the small ones tend to be in the gaps between the large ones) or when particles are anisotropic (they can no longer rotate freely in all directions without feeling the influcence of their neighbours). For strongly interacting particles, such as charged ones in low ionic strength solvent, the concentrations at which the theory breaks down can be relativley low.

[RichardHeenan]

Trac update at 2018/05/18 15:53:58: richardh commented:

Whilst we are modifying the S(Q) multiplication here for beta(Q) we might also implement some or all of SasView/sasview#888 to allow users further controls to set or fit the effective volume and/or effective radius in S(Q). The present system that forces both of these parameters to values based on those in P(Q) is, being polite, in my opinion rather too restrictive.

[pkienzle]

Trac update at 2018/05/18 16:26:52: pkienzle commented:

Some models will be more complicated since the kernel itself is defined as using a P*S.

For example, stacked disk uses
P(q)^2 (N + 2 S(q))
where
S(q) = sum_k (N-k)cos(k d q_c) e^(k (d q_c sigma)^2)

The current software avoids this by not allowing P*S when P is stacked_disk.

[pkienzle]

Trac update at 2018/05/18 16:45:12: pkienzle commented:

Ticket SasView/sasview#1142 (1D speed improvements) suggests unrolling the 1D integration loop to increase the exploitable parallelism on modern graphics cards. Currently parallelism is limited to the number of q points in the curve, which means a GPU with 1000 processors will be mostly idle when computing a sans curve with 100 points. While retooling the models for beta approximation, we can set them up to compute the different q_a/q_b/q_c for the given q in parallel.

We can also make progress on ticket #535 (adaptive integration). Since the q points will be evaluated independently we do not need a uniform mesh, and can instead evaluate more q_a/q_b/q_c points when evaluating larger q. If we tie the point density to the largest dimension of the shape then we can probably get away without adaptive integration.

[RichardHeenan]

Trac update at 2018/05/21 15:24:54: richardh commented:

I am unsure whether beta(Q) either could or should be applied to 2d data from oriented particles, perhaps others might like to comment. I suspect that we should for now restrict ourselves to 1d data.

Does anyone know of sasview users who use 2d oriented particle models with an S(Q)?

[RichardHeenan]

Trac update at 2018/05/21 15:32:03:

• richardh changed _comment0 from:

Replying to [comment:3 pkienzle]:

The three lammellar stack models are similar (are they also not allowed an S(Q) ?), I suspect that since they all have an included 1d S(Q) we might need a beta(Q) if the sheet or disc thickness is polydisperse ???  However I would not make dealing with this a high priority - perhaps a separate ticket?

Some models will be more complicated since the kernel itself is defined as using a P*S.

For example, stacked disk uses
P(q)^2 (N + 2 S(q))
where
S(q) = sum_k (N-k)cos(k d q_c) e^(k (d q_c sigma)^2)

The current software avoids this by not allowing P*S when P is stacked_disk.

to:

1527092326138738

• richardh commented:

Replying to [comment:3 pkienzle]:

The three lammellar stack models are similar (are they also not allowed an S(Q) ?), I suspect that since they all have an included 1d S(Q) we might need a beta(Q) if the sheet or disc thickness is polydisperse ??? However I would not make dealing with this a high priority - perhaps a separate ticket?

As discussed later (23May2018), these stacks have an internal 1d S(Q), but might also have an external inter- randomly oriented stack 3d S(Q). So we need to decide whether the internal S(Q) is one for which beta(Q) is needed, and then whether we actually can calculate of the stack to use with an inter-stack beta(Q).

Some models will be more complicated since the kernel itself is defined as using a P*S.

For example, stacked disk uses
P(q)^2 (N + 2 S(q))
where
S(q) = sum_k (N-k)cos(k d q_c) e^(k (d q_c sigma)^2)

The current software avoids this by not allowing P*S when P is stacked_disk.

[RichardHeenan]

Trac update at 2018/06/20 13:22:35:

• richardh changed attachment from "" to "structure_factors_sasfit.pdf"
• richardh commented:

S(Q) in sasfit manula pages

[RichardHeenan]

Trac update at 2018/06/20 13:23:20: richardh commented:

Later we really ought to implement at least the "local monodisperse approximation" as per section 4.1.3 of the sasfit manual (to be attached), and no doubt other methods, so we should anticipate menus and controls for several possible choices.