Opened 8 years ago

Closed 8 years ago

#789 closed defect (fixed)

stacked disk scale doesn't match corresponding cylinder model

Reported by: pkienzle Owned by: butler
Priority: major Milestone: SasView 4.1.0
Component: sasmodels Keywords:
Cc: Work Package: SasView Bug Fixing

Description

Stacked disk is off by a factor of n_stacking as compared to the corresponding cylinder:

$ sascomp -mono stacked_disks:cylinder -pars length=":n_stacking*(2*thick_layer+thick_core)" sld_layer=sld_core sld=:sld_layer sigma_d=0 n_stacking=2 background=0
==== stacked_disks =====
scale: 0.01
background: 0
thick_core: 10
thick_layer: 10
radius: 15
n_stacking: 2
sigma_d: 0
sld_core: 4
sld_layer: 4
sld_solvent: 5
==== cylinder =====
scale: 0.01
background: 0
sld: 4
sld_solvent: 5
radius: 15
length: 60
INFO:root:building stacked_disks-float32-667DB7B2 for OpenCL HD Graphics 4000
OCL32 t=17.75 ms, intensity=3
INFO:root:building cylinder-float32-59E9AD73 for OpenCL HD Graphics 4000
OCL32 t=15.96 ms, intensity=5
|OCL32-OCL32|          max:2.121e-02  median:2.120e-02  98%:2.121e-02  rms:2.074e-02  zero-offset:+2.070e-02
|(OCL32-OCL32)/OCL32|  max:5.000e-01  median:5.000e-01  98%:5.000e-01  rms:5.000e-01  zero-offset:+5.000e-01

Looking at the code (stacked_disks.c:69), pq is computed for a single oreo; this should be scaled by the number of oreos in the stack.

Introducing sigma_d, the variation in stack height is sqrt(sum(sigma_d^2)), or sigma_d*sqrt(n). Since sasview uses polydispersity, need to scale this variation by the cylinder height, which is (2*shell+core)*n. With the pq correction, the result is surprisingly close:

$ sascomp -mono stacked_disks:cylinder -pars length=":n_stacking*(2*thick_layer+thick_core)" sld_layer=sld_core sld=:sld_layer n_stacking=10 -random -highq length_pd=":sigma_d*sqrt(n_stacking)/((2*thick_layer+thick_core)*n_stacking)" -double

Change History (6)

comment:1 Changed 8 years ago by pkienzle

The stacked disk spacing D is set such that the gap between disks is zero:

http://www.sasview.org/docs/user/models/stacked_disks.html

The structure factor uses the spacing between centers as a parameter, set to 2 * layer thickness + core thickness. It does not allow for solvent between the disks. Should it?

comment:2 Changed 8 years ago by butler

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

comment:3 Changed 8 years ago by butler

Apparently no, there is no solvent between the disks. As stated in the documentation this is for non exfoliated ("tactoids") stacks of disks and was developed it seems for clay particles such as laponite.

comment:4 Changed 8 years ago by butler

There are several issues with this model which seems to have been developed by NIST staff in the early 2000 based on a number of known forms but never published independently? Issues:

  • The documentation (both original IGOR and SasView) make clear that the normalization N is the number density of individual disks not of stacks. However both the IGOR code and the SasView code normalize by the stack number density. Thus by multiplying by the number of disks in a stack converts number density of stacks to number density of disks and indeed doing so the cylinder model is now identical to the stacked disk model (assuming core and layer have the same SLD and use a sigma of nearest neighbor spacing of zero)
  • Both the IGOR and SasView documentation state that the exponent in the S(Q) term is q*cos(alpha) but both codes use q*d*cos(alpha). However it is not obvious what the effect of this term is since there is nothing I can think of to compare to once we allow a non zero sigma_d (and if it is zero that term becomes a multiply by one so has no effect). However d*cos(alpha) is just the projection of d into qparallel. Thus cos(alpha) alone makes no sense so assume the code is correct in this case and documentation is wrong.
  • SasView documentation also shows sigma_d in that same exponent term to not be squared while the IGOR documentation shows it squared. This is effectively a Debye-Waller term (exp[-q2 x2]). And x must be d*cos(alpha)*sigma_d assuming sigma_d is given as a fraction of x and of course x should be x in the direction of q. Hence the square shoudl be correct and moreover is another reason that the previous point should be d*cos(alpha) not just cos(alpha) Further both sets of code do use the square term.
Last edited 8 years ago by butler (previous) (diff)

comment:5 Changed 8 years ago by butler

There is one thing that remains uclear to me: What exactly is the effect of a non-zero sigma_d physically. Is it in fact a way of introducing polydispersity in core and layers (though exactly what layer then is the most polydisperse? or is it a proportional stretching of the cylinder? and if so how does that change the volume of the effective radius one should use when multiplying by an S(Q) between stacks?) or does in just introduce varying layers of water between the disks (though then it probably shouldn't be a Gaussian? having a cut-off when zero water exists? and again what is the implication for effective volume of disks?)

These however should have been addressed in the apparently non-existent paper describing the model (or equivalently the documentation) and is way beyond the scope of this ticket. Given it is a long standing model suggest we leave it with the new propoer n_stacking normalization until someone identifies an error.

comment:6 Changed 8 years ago by butler

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

In 98ce141a6e091b02f8139ab3b235c16dafbce663/sasmodels:

correct normalization problem in stacked_disk fixes #789. Also heavy
cleanup and correction of equations to match code as well as
standardization of the model documentation addressing #646.

Note: See TracTickets for help on using tickets.