qt5 - Separate composition of mixture models in GUI (Trac #1149)

[sasview-bot]

''ported from JIRA, '''SASVIEW-973''':''

---

'''Torin Cooper-Bennun, 26 July 2018 11:10'''

Mixture models (a.k.a. sum/multiply models, for current intents and purposes) separate parameters of their component models using prefixes (A_sld, B_sld, and so on).

We are on the way to using sub-headings in the parameters table instead (see [https://jira.esss.lu.se/browse/SASVIEW-966 SASVIEW-966] [and comments in trac, #609]). To implement this for mixture models, an intermediate layer (upon model loading) is needed to extract the parameters by component and display them without prefixes; then, when they are manipulated, translate from the non-prefixed version to the prefixed version, in order to interact with the model itself correctly.

The first step seems okay, since modelinfo, I think, contains the necessary information to get the name of the model component from the parameter's prefix.

The second step is a bit more involved. One possibility is to have each non-prefixed parameter in the Qt model be associated with a data item which contains the real parameter name. Whatever happens, various routines will need updating to deal with this case, because currently only the item's text is used to identify the parameter.

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

{
    "status": "new",
    "changetime": "2018-09-09T08:02:13",
    "_ts": "2018-09-09 08:02:13.911024+00:00",
    "description": "''ported from JIRA, '''SASVIEW-973''':''\n\n----\n'''Torin Cooper-Bennun, 26 July 2018 11:10'''\n\nMixture models (a.k.a. sum/multiply models, for current intents and purposes) separate parameters of their component models using prefixes (A_sld, B_sld, and so on).\n\nWe are on the way to using sub-headings in the parameters table instead (see [https://jira.esss.lu.se/browse/SASVIEW-966 SASVIEW-966] [and comments in trac,\u00a0#475]). To implement this for mixture models, an intermediate layer (upon model loading) is needed to extract the parameters by component and display them without prefixes; then, when they are manipulated, translate from the non-prefixed version to the prefixed version, in order to interact with the model itself correctly.\n\nThe first step seems okay, since modelinfo, I think, contains the necessary information to get the name of the model component from the parameter's prefix.\n\nThe second step is a bit more involved. One possibility is to have each non-prefixed parameter in the Qt model be associated with a data item which contains the real parameter name. Whatever happens, various routines will need updating to deal with this case, because currently only the item's text is used to identify the parameter.",
    "reporter": "tcbennun",
    "cc": "richardh, pkienzle",
    "resolution": "",
    "workpackage": "Beta Approximation Project",
    "time": "2018-07-26T10:41:55",
    "component": "SasView",
    "summary": "qt5 - Separate composition of mixture models in GUI",
    "priority": "critical",
    "keywords": "",
    "milestone": "SasView 5.0.0",
    "owner": "tcbennun",
    "type": "enhancement"
}

[sasview-bot]

Trac update at 2018/08/21 12:36:26: tcbennun changed attachment from "" to "subheadings_volfraction.png"

[sasview-bot]

Trac update at 2018/08/21 12:37:33: tcbennun commented:

In the ESS_GUI_beta_approx branch, product model parameters are all shown separated by constituent model:

[[Image(subheadings_volfraction.png)]]

[sasview-bot]

Trac update at 2018/09/09 08:02:13: tcbennun commented:

Product model params are now separated by P(Q), S(Q) by subheadings in ESS_GUI.

Doing the same for mixture models is a big task...

[butlerpd]

@pkienzle and/or @RichardHeenan - Can I assume that this old Torin ticket which is a sister of SasView/sasmodels#235 in the sasmodels repo is now obsolete (i.e. either done or superseded by other tickets?) If so we can close both of these I think.

[RichardHeenan]

@pkienzle and/or @RichardHeenan - Can I assume that this old Torin ticket which is a sister of SasView/sasmodels#235 in the sasmodels repo is now obsolete (i.e. either done or superseded by other tickets?) If so we can close both of these I think.

No idea of the status of all this, as mentioned above, it could be a large task.

Suspect we need a detail review of sums and mixtures etc, how they appear in the gui, how users build them, especially more complex ones with several parts, and how they are dealt with internally.

e.g. P1 + P2 + P3 or P1.S1 + P2.S2 + P3 where all 3 models have say radius, it might help users to still have A_radius, B_radius, C_radius etc.

e.g. (P1 + P2).S1 is probably not allowed, as I can't think of a legitimate use.