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 and radius
• core_shell_bicelle_elliptical uses x_core and radius_minor (which is wrong if x_core < 1)
• core_shell_ellipsoid uses x_core, radius_equat_core and x_polar_shell
• rectangular prism uses b2a_ratio, which is a related concept
• triaxial_ellipsoid uses radius_equat_major/radius_equat_minor, however the model no longer requires one to be larger than the other

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

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

direction

• parallelpiped, et al. use a-b-c for the different dimensions. Maybe use x-y-z corresponding to detector x-y and beam z for the sample in canonical position theta=phi=psi=0; could also use width-height-length
• rectangular_prism uses a, b2a and c2a, where a-b-c corresponds to x-y-z
• triaxial ellipsoid uses radius_polar, radius_equat_major and radius_equat_minor; maybe radius_z, radius_y and radius_x instead.
• ellipsoid uses radius_polar, radius_equatorial; maybe radius_z and radius_xy instead.

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