Fix model parameter nomenclature to be standardized

[butler]

Despite discussion at codecamp IV that all parameters should be standardized along a set of rules, as is expected in such a big effort a number of inconsistncies have crept in. As per ticket #643 these need to be fixed before the final release.

[butler]

In 30fbe2eda4d6f97acc840bd5e605de3829caf3c7/sasmodels:

Last of parameter normalization. Fixes #649

[pkienzle]

Model names inconsistencies (probably more of these)

elliptical_cylinder, flexible_cylinder_elliptical:

• shouldn't that be flexible_elliptical_cylinder

Parameter name inconsistencies

axis ratio

• elliptical_cylinder, flexible_cylinder_elliptical use axis_ratio
• core_shell_ellipsoid uses x_core, x_polar_shell
• core_shell_bicelle_elliptical uses x_core
• rectangular prism uses b2a_ratio, which is a related concept

concentration

• be_polyelectrolyte uses polymer_concentration, salt_concentration
• hayter_msa uses concentration_salt

correlation length

• most models use cor_length
• teubner-strey uses xi
• mass fractal and surface fractal use cutoff_length

d-spacing

• Teubner-Strey uses d
• lamellar models use d_spacing
• fcc/bcc/sc use dnn.

d-spacing distortion

• lamellar_stack_paracrystal uses sigma_d
• fcc/bcc/sc uses d_factor
• stacked_disks also uses sigma_d, but in a way that acts more like sigma_thick since the model does not support solvent gaps between disks

equatorial radius

• most models use radius_equatorial or radius_equat_core
• elliptical_cylinder users radius_minor

• triaxial_ellipsoid uses radius_equat_major/radius_equat_minor which suggests one must be bigger than the other. Do we want a more generic a,b instead of major,minor? Or radius_equatorial, radius_equatorial_ratio for a/b?

fractal dimension:

• shouldn't it be dim_fractal rather than fractal_dim
• also, scale_guinier or length_kuhn

length

• most models use length or length_part if there are multiple lengths
• be polyelectrolyte uses monomer_length
• linear pearls and pearl necklace use edge_sep rather than length_string

thickness

• With only one thickness the model uses "thickness". With many different thickness it uses thick_part for each part.
• concentration is spelled out in full.
• equatorial is sometimes abbreviated

n

• most models use n or n_parts
• unified_power_Rg uses level instead of n_levels
• linear_pearls, pearl_necklace use num_pearls
• stacked_disks uses n_stacking instead of n_cores
• star_polymer uses arms instead of n_arms
• ndensity for micelle could be replaced by number_density

welldepth, wellwidth

• squarewell should use width_well and width_depth following the naming conventions, or just width and depth since there is no confusion

[pkienzle]

Note that conversion_table.py needs to be updated with any changes so that SasView 3.1 models can be loaded.

[butler]

Erkan Senses suggests that rg_squared implies of the whole polymer wheras it is in fact only rg of the arm. Asks if it can be named in a way that it is clear.

[pkienzle]

An additional inconsistency:

n

• lamellar stack models use Nlayers rather than n_stacking or n_layer; perhaps use the same term for lamellar stacks as stacked disks.

Use python -m sasmodels.list_pars to show all parameters used, and use python -m sasmodels.list_pars -v to show which models they appear in.

[pkienzle]

star_polymer uses arms for the number of arms. Should this be an integer? In which case, the parameter should be 'n_arms' for consistency.

[smk78]

Looking at Higgins & Benoit (as I don't have access to the reference given for the star model) I suspect that arm is a relatively modern term and that branch was the original terminology.

That being so, I find it difficult to comprehend how you can have a non-integer number of branches.

The branches may be of different length (cf molecular weight, degree of polymerisation), but that is a different issue.

So I would vote that we make arms into n_arms.

[butler]

As we now have a converter, it is not super imperitive we get everything right in this release though sooner is always better - still not a blocker so downgrading to "major"

[pkienzle]

Comment 7 from ticket #815:

Looking at Higgins & Benoit (as I don't have access to the reference given for the star model) I suspect that arm is a relatively modern term and that branch was the original terminology.

That being so, I find it difficult to comprehend how you can have a non-integer number of branches.

The branches may be of different length (cf molecular weight, degree of polymerisation), but that is a different issue.

So I would vote that we make arms into n_arms.

[pkienzle]

elliptical cylinder uses radius_minor and axis_ratio whereas triaxial ellipsoid uses radius_equat_major and radius_equat_minor.

Note: instead of axis_ratio=major/minor, could use eccentricity = sqrt(1 - (minor/major)^2).

[butler]

Moving this to 4.2 as discussed at Tuesday's meeting