Fix model parameter nomenclature to be standardized (Trac #649)

[butlerpd]

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 #775 these need to be fixed before the final release.

Migrated from http://trac.sasview.org/ticket/649

{
    "status": "reopened",
    "changetime": "2019-03-03T00:48:43",
    "_ts": "2019-03-03 00:48:43.592800+00:00",
    "description": "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.",
    "reporter": "butler",
    "cc": "",
    "resolution": "",
    "workpackage": "SasModels Model Issues",
    "time": "2016-09-05T14:30:50",
    "component": "SasView",
    "summary": "Fix model parameter nomenclature to be standardized",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView 4.3.0",
    "owner": "butler",
    "type": "defect"
}

[butlerpd]

Trac update at 2016/09/05 14:45:45:

• butler changed owner from "" to "butler"
• butler changed status from "new" to "accepted"

[butlerpd]

Trac update at 2016/10/01 16:53:43:

• butler commented:

In changeset 30fbe2eda4d6f97acc840bd5e605de3829caf3c7:

#!CommitTicketReference repository="sasmodels" revision="30fbe2eda4d6f97acc840bd5e605de3829caf3c7"
Last of parameter normalization. Fixes #780

• butler changed resolution from "" to "fixed"
• butler changed status from "accepted" to "closed"

[pkienzle]

Trac update at 2016/10/27 16:40:50:

• pkienzle changed _comment0 from:

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; at minimum it should use x_core, x_shell or x_polar_core, x_polar_shell
• 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

to:

1477595997053719

• pkienzle changed _comment1 from:

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; at minimum it should use x_core, x_shell or x_polar_core, x_polar_shell
• 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

to:

1490233016738799

• pkienzle changed _comment2 from:

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

to:

1490288062656983

• pkienzle commented:

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]

Trac update at 2016/10/27 16:41:12:

• pkienzle changed milestone from "SasView 4.0.0" to "SasView 4.1.0"
• pkienzle changed resolution from "fixed" to ""
• pkienzle changed status from "closed" to "reopened"

[butlerpd]

Trac update at 2016/10/27 19:19:25: butler changed _comment0 from "Note that conversion_table.py needs to be updated with any changes so that SasView 3.1 models can be loaded." to "1479244180753350"

[pkienzle]

Trac update at 2016/10/27 19:19:25: pkienzle commented:

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

[butlerpd]

Trac update at 2016/11/15 21:14:09: butler commented:

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]

Trac update at 2016/12/07 21:16:55: pkienzle commented:

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]

Trac update at 2016/12/20 20:42:24: pkienzle commented:

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]

Trac update at 2016/12/21 11:33:00: smk78 commented:

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''.

[butlerpd]

Trac update at 2017/01/23 22:22:13:

• butler commented:

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"

• butler changed priority from "blocker" to "major"

[pkienzle]

Trac update at 2017/02/27 17:29:39: pkienzle commented:

Comment 7 from ticket #912:

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]

Trac update at 2017/03/21 14:00:24: pkienzle commented:

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).

[butlerpd]

Trac update at 2017/03/21 15:17:45:

• butler commented:

Moving this to 4.2 as discussed at Tuesday's meeting

• butler changed milestone from "SasView 4.1.0" to "SasView 4.2.0"
• butler changed workpackage from "SasView Bug Fixing" to "SasModels Redesign"

[butlerpd]

Trac update at 2017/10/27 13:51:53: butler changed milestone from "SasView 4.2.0" to "SasView 4.3.0"

[butlerpd]

Trac update at 2019/03/02 00:18:03: butler changed workpackage from "SasModels Redesign" to "SasModels New Model"

[butlerpd]

Trac update at 2019/03/03 00:48:43: butler changed workpackage from "SasModels New Model" to "SasModels Model Issues"