Opened 4 weeks ago

Last modified 2 weeks ago

#1201 new defect

default effective radius type

Reported by: pkienzle Owned by:
Priority: major Milestone: sasmodels 1.0
Component: sasmodels Keywords:
Cc: Work Package: Beta Approximation Project

Description

In sasmodels, all platforms.

For the beta_approx branch we are using a default of 0 as the effective radius type (i.e., use the value from the parameter table instead of the form factor calculation) rather than whatever the model was returning before.

Do we want this as the default?

Or should we set the default to 1 and make sure that is the "best" effective radius to use when computing P@S?

There is also an issue with reloading a saved P@S fit from 4.2 and earlier, which all implicitly use old ER radius type.

Do we try to set the equivalent effective radius type parameter in the model?

Or do we let it silently use the default value for radius_effective from S?

Note: if the old ER is not the first effective radius type for any model then conversion with need a table for each model giving the number to use. Not difficult, but a detail to test if we decide to support correct reloading of old P@S models.

Change History (3)

comment:1 Changed 4 weeks ago by richardh

Hmm this is going to be tricky. Suspect that for backwards compatibility 5.0 ought to default to doing what 4.2 would do, thus as Paul K says to make sure that effective radius defaults to the one used by 4.2  This would reduce or perhaps remove the need for conversions.

Would it help, before we get too far along with this, to change the default type of 0 to mean use ER from P(Q) rather than take a user supplied value?

comment:2 Changed 4 weeks ago by pkienzle

The code in product.py needs to know whether to use the user value or the computed value independent of model. I'm guessing the GUI code also needs to know, given that it places the computed value into the user value slot when a computed value is requested. So best to leave that as option 0.

Easiest is to set the default to 1 and make sure that the first effective radius is the one defined in sasview 4.1.

comment:3 Changed 3 weeks ago by pkienzle

A lot of the old models use some function which is perhaps the average radius of the equivalent cylinder, but which is not implemented for the new models. There are a couple of models which have an equivalent mode different from 1. There are a number of models that did not have ER before, but those ones won't be used with structure factors so it doesn't matter to the loader what they used to be. The new models all use the outer radius equivalent sphere, except mono gauss coil which uses Rg.

beta_approx branch radius_effective_mode value for the old style ER function. Uses — for not implemented and N/A for no equivalent.

Model R_eff mode old ER
barbell N/A
capped_cylinder N/A
core_multi_shell 1 outer radius
core_shell_bicelle N/A
core_shell_bicell_elliptical N/A
core_shell_bicell_elliptical_belt_rough N/A
core_shell_cylinder N/A outer cylinder excl. vol
core_shell_ellipsoid N/A eq. cylinder excl. vol
core_shell_parallelepiped N/A eq. cylinder excl. vol
core_shell_sphere 1 outer radius
cylinder N/A excl. vol
ellipsoid 2 radius from curvature
elliptical_cylinder N/A eq. cylinder excl. vol
fractal
fractal_core_shell outer radius
fuzzy_sphere 1 radius
hollow_cylinder N/A average radius
hollow_rectangular_prism N/A eq. cylinder excl. vol
hollow_rectangular_prism_thin_walls N/A eq. cylinder excl. vol
mono_gauss_coil N/A
multilayer_vesicle 1 outer radius
onion 1 outer radius
parallelepiped N/A equivalent cylinder excl. vol
pearl_necklace equivalent volume
pringle N/A equivalent cylinder excl. vol
raspberry N/A
rectangular_prism N/A equivalent cylinder excl. vol
sphere 1 radius
spherical_sld 1 outer radius
triaxial_ellipsoid N/A equivalent ellipsoid average curvature
vesicle 1 outer radius

The old cylinder ER expression is as follows:

def ER(radius, length):
    ddd = 0.75 * radius * (2 * radius * length + (length + radius) * (length + pi * radius))
    return 0.5 * (ddd) ** (1. / 3.)

I don't see it in [Pedersen 1997], and don't know where it comes from. Maybe [Fournet 1951]?

Parallelepipeds used the long axis to define the equivalent cylinder.

Would adding Rg for everything be useful? This is yet another

Last edited 2 weeks ago by pkienzle (previous) (diff)
Note: See TracTickets for help on using tickets.