Opened 6 years ago
Closed 6 years ago
#1201 closed defect (fixed)
default effective radius type
Reported by: | pkienzle | Owned by: | GitHub <noreply@…> |
---|---|---|---|
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 (4)
comment:1 Changed 6 years ago by richardh
comment:2 Changed 6 years 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 6 years 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
comment:4 Changed 6 years ago by GitHub <noreply@…>
- Owner set to GitHub <noreply@…>
- Resolution set to fixed
- Status changed from new to closed
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?