Separate composition of mixture models in GUI (Trac #1153)

[sasview-bot]

'''''From JIRA, SASVIEW-973:'''''

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 SASVIEW-966 [''Organise parameter table by model component''; trac #1161]). 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.

---

'''''From email correspondence with @pkienzle:'''''

For the 5.0 UI where you are talking about keeping the parameters for S and P separate, a cleaner version of product.py is possible. Currently, I have to tear apart the parameter structure before calling the individual S and P with their own sets of parameters. It would be better to build the two separate parameter structures independently. Similarly for mixture models, which ought to be available without having to create a plugin model for each combination.

I propose that you assume such an interface exists, and that you can call it with the individual parameter sets decoupled. Within this interface, we can either construct an existing product/mixture model on the fly, or restructure product/mixture to use the decoupled parameters, whichever is more expedient.

If you decide to follow the current scheme which views the combined model as a single parameter set (not an unreasonable option given the number of changes required on the UI and project save/load to keep them separate) then you can target the 4.3 interface directly.

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

{
    "status": "new",
    "changetime": "2018-09-09T07:44:53",
    "_ts": "2018-09-09 07:44:53.808569+00:00",
    "description": "'''''From JIRA, SASVIEW-973:'''''\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 SASVIEW-966 [''Organise parameter table by model component''; trac #1116]). 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.\n\n----\n\n'''''From email correspondence with @pkienzle:'''''\n\nFor the 5.0 UI where you are talking about keeping the parameters for S and P separate, a cleaner version of product.py is possible.  Currently, I have to tear apart the parameter structure before calling the individual S and P with their own sets of parameters.  It would be better to build the two separate parameter structures independently.  Similarly for mixture models, which ought to be available without having to create a plugin model for each combination.\n\nI propose that you assume such an interface exists, and that you can call it with the individual parameter sets decoupled.  Within this interface, we can either construct an existing product/mixture model on the fly, or restructure product/mixture to use the decoupled parameters, whichever is more expedient.\n\nIf you decide to follow the current scheme which views the combined model as a single parameter set (not an unreasonable option given the number of changes required on the UI and project save/load to keep them separate) then you can target the 4.3 interface directly.",
    "reporter": "tcbennun",
    "cc": "",
    "resolution": "",
    "workpackage": "Beta Approximation Project",
    "time": "2018-08-09T10:36:29",
    "component": "SasView",
    "summary": "Separate composition of mixture models in GUI",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView Next Release +1",
    "owner": "",
    "type": "enhancement"
}

[sasview-bot]

Trac update at 2018/08/09 14:00:31: tcbennun commented:

The approach in the GUI of creating a mixture model easily (on-the-fly, as it were, without saving a plugin model) is tricky. The Model tab is too close to being cluttered to introduce a new section of controls as it is.

The intention is for users to easily select multiple form factors, and for the resulting model to be a sum of these. The parameter table would show each form factor's parameters under a sub-heading (this is already achieved in the case of product models). Questions arise such as:

1. Where are these controls placed?
2. Does the option remain to select a structure factor to multiply with the form factor sum?
3. If so, can we use the beta approximation in this calculation?

[sasview-bot]

Trac update at 2018/08/09 14:01:25:

• tcbennun commented:

(Not working on this until more urgent beta-approximation stuff is through.)

• tcbennun changed priority from "critical" to "major"

[sasview-bot]

Trac update at 2018/09/09 07:44:53: tcbennun changed milestone from "SasView 5.0.0" to "SasView Next Release +1"

[butlerpd]

@pkienzle - I am thinking that this ticket is now obsolete even if not everything is "done?"

[butlerpd]

having found the sister ticket SasView/sasview#1833 adding @RichardHeenan to the question.