core_shell_bicelle_elliptical need debug 2d data

[richardh]

core_shell_bicelle_elliptical is a new model.

Limiting cases for 1d data agree with other models such as cylinder, core-shel_cylinder and stacked_disks.
Need to finish this off by debugging its 2d output, which does not look right yet.

[richardh]

If I set axial ratio of core to 1, then set rectangular polydispersity for both theta and phi to have std dev = 90/sqrt(12) = 51.9615 degrees, that should average over all orientations. I do indeed get a circular 2d pattern, then if I do "circular average" and fit the 1d data give very close to what the 1d model expects, bearing in mind my 179 x 179 point integration may not be perfect. So my 2D calculation may be OK.

[As mentioned in email, we could do with some better ways of testing 2d output.]

HOWEVER, if I set axial ratio x_core=3, and add a third polydispersity integral over angle psi withn the ellipsoid, then slowly of course, I get a 2d array full of something close to zero, which is not what I expect.

Do I recall that there is an earlier issue here with triple polydispersity integration?

[richardh]

---

From: Paul Kienzle paul.kienzle@…
Sent: 23 March 2017 01:38
To: Heenan, Richard (STFC,RAL,ISIS)
Subject: core shell bicelle

Richard,

Comparing core shell bicelle to core shell bicelle elliptical 2D with an axis ratio of 1 I'm getting a very large difference even with an axis ratio equal to 1:

I believe this is due to the following:

cs bicelle:

const double be2 = sas_2J1x_x( qq*(rad+radthick)*sin_alpha );

cs bicelle ellip:

const double r = rad*sqrt(square(x_core*cos_nu) + cos_mu*cos_mu);
…
const double be2 = sas_2J1x_x( qq*(r + radthick) );

That is, you are not including the projection of radthick in the rotated view.

When I change cs bicelle ellip to the following it compares:

const double rad_minor = rad;
const double rad_major = rad*x_core;
const double r_hat = sqrt(square(rad_major*xhat) + square(rad_minor*yhat));
const double rshell_hat = sqrt(square((rad_major+radthick)*xhat)

+ square((rad_minor+radthick)*yhat));

const double be1 = sas_2J1x_x( q*r_hat );
const double be2 = sas_2J1x_x( q*rshell_hat );

Note that in the redefined orientation space, cos_val is zhat, the projection onto the z-axis, cos_mu is yhat, the projection onto the y-axis and cos_nu is xhat, the projection onto the x-axis. zhat goes to cos_alpha in the rotationally symmetric models. I'm guessing sqrt(xhat^{2 + yhat}2) goes to sin_alpha, but I haven't checked.

Anyway, I will commit this to the ticket-890 branch so you can play with it if you would like.

I noted the following on ticket #649 (nomenclature):

elliptical cylinder and flexible cylinder elliptical use axis_ratio instead of x_core, but core_shell_ellipsoid uses x_core.

[richardh]

Hi Paul,

Well spotted, have not got time just yet to follow through the detail, as you are now well ahead of me in attempting to understand the 2d for asymmetric particles.
But if it now give the same answers when x_core=1 that is good!

With the shells invisible and/or same sld as core you should be able to check against elliptical cylinder, which is what I have done for the 1d data.

"Axis_ratio" is ambiguous as to whether it applies to the outer shape or to the inner core, could change x_core to axis_ratio_core if you like, though the equations start to look ugly with such long names. Core shell ellipsoid will be similar.

Richard

[pkienzle]

The 2D patterns for cs bicelle ellip and ellip cyl match when core sld = shell sld and the appropriate parameter conversions are made:

• radius_minor = radius+thick_rim
• length = length+2*thick_face
• axis_ratio = (radius*x_core+thick_rim)/(radius+thick_rim)

Here is the sascomp command that shows it:

sascomp core_shell_bicelle_elliptical,elliptical_cylinder sld_rim=sld_core sld_face=sld_core sld=sld_core radius_minor=radius+thick_rim length=length,length+thick_face*2 axis_ratio="(radius*x_core+thick_rim)/(radius+thick_rim)" -2d -mono -pars -random -midq

The 1D integration also matches, but the difference is a bit large at high q (up to 6%).

Regarding nomenclature, I'll leave it to others to figure out which names to use.

Incidentally, elliptical_cylinder uses radius_minor while cs bicelle elliptical uses radius (added to #649). Also, the description of x_core says polar/equatorial but they are equatorial a and b in the model.

[pkienzle]

realspace.py now includes the EllipticalBicelle? shape as the cscyl model.

Monte Carlo simulations of 1-D and 2-D patterns do not calculated values for elliptical bicelle for either 1D or 2D. Sampling seems to match description of the model, and the Monte Carlo does work for other models such as elliptical cylinder and core-shell parallelepiped. This is further evidence that there are errors in sasmodels elliptical bicelle model.

To see:

    # 1-D
    PYTHONPATH=. python explore/realspace.py -s 20000 cscyl -d 1 -p
    # 2-D
    PYTHONPATH=. python explore/realspace.py -s 20000 cscyl -d 2 --view=90,0,0 -p

Compare these results for those for ellcyl.

Note the parameter table says x_core = r_polar/r_equatorial rather than r_major/r_minor. The picture implies the opposite: radius seems to be the long axis and the other axis the short axis.

Further note: using radius, radius_a, radius_b, radius_c instead of radius, polar, major, minor, equatorial, equatorial_major, equatorial_minor across all models would be consistent between ellipsoid and parallelepiped models, and easier to describe since the a-b-c axes of the sample aligns with the x-y-z axes of the laboratory frame.

[pkienzle]

Fixed the simulation and the parameter description. Model now verified via Monte Carlo.

[richardh]

The picture and much else for core_shell_bicelle_elliptical were re-used from the circular core_shell_bicelle

The parameter descriptions were indeed likely a bit unclear, but you can only say x_core=r_major/r_minor if x_core ≥ 1, so that r_major is the larger one, which is not always the case here. Should we enforce this by setting the range to be from +1 to infinity ? e.g. as noted in the docs to avoid having two solutions, or does it make a difference to the numerical integrations?