qt5 user level S(Q) tab (Trac #1115)

[RichardHeenan]

New S(Q) controls tab to decide what type of P(Q)S(Q) calculation the user requires.
Note that the contents of this will likely have to vary depending on which P(Q) is being used, and if we allow P1(Q)S1(Q) + P2(Q)S2(Q) there may need to be more than one tab appear as both S1 and S2 could have different controls.

More suggestions to follow after setting up some more tickets ....

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

{
    "status": "closed",
    "changetime": "2018-09-09T07:49:55",
    "_ts": "2018-09-09 07:49:55.676455+00:00",
    "description": "New S(Q) controls tab to decide what type of P(Q)S(Q) calculation the user requires.\nNote that the contents of this will likely have to vary depending on which P(Q) is being used, and if we allow P1(Q)S1(Q) + P2(Q)S2(Q) there may need to be more than one tab appear as both S1 and S2 could have different controls.\n\nMore suggestions to follow after setting up some more tickets ....",
    "reporter": "richardh",
    "cc": "",
    "resolution": "wontfix",
    "workpackage": "Beta Approximation Project",
    "time": "2018-07-01T21:08:45",
    "component": "SasView",
    "summary": "qt5 user level S(Q) tab",
    "priority": "critical",
    "keywords": "",
    "milestone": "SasView 5.0.0",
    "owner": "",
    "type": "enhancement"
}

[RichardHeenan]

Trac update at 2018/07/02 21:52:26: richardh commented:

The more I think about this the more I think that we should be using the constraints system for linking parameters in S(Q) to those in P(Q).  Sasview could provide options to set up constraints for a range of typical options to link to the immediately preceding P(Q).  

Users with more complex calculations could then write their own constraints to sort out the mess, for case such as (P1(Q) +P2(Q))*S(Q).

This would require a way for constraint relationships to access the ER_ and likely VR_ functions associated with a given model.

Would be good to mock up how this might look in the QT gui.

[RichardHeenan]

Trac update at 2018/07/02 22:08:32: richardh commented:

I presume that switches for whether beta(Q) or other corrections are made to S(Q) could be based on what is currently done for "Q resolution smearing" or  "data weighting scheme".

Rarely a fit page might have more than one S(Q), should each S(Q have its own tab, or should there be just one?

[RichardHeenan]

Trac update at 2018/07/02 22:27:49: richardh commented:

Suggest we rename current ER in P(Q) models to indicate what it is actually calculating, then allow more than one ER_ function per model, such as ....

ER_mean_curvature 

ER_equivalent_sphere

ER_maximum_radius

ER_minimum_radius

there might be others, e.g. for a cylinder ER_half_length  and ER_radius_cylinder

All of the above would have to be provided in the P(Q) model, but some could be user generated by a 

simple equation, such as those used in constraints.

Most importantly the user has to be able to choose to fix ER or let it freely fit.

QUESTION - when a radius or size parameter is polydisperse are users going to always want the number average value of ER or would they for example like the option of volume weighted average? - or still other R!^n!^ weighted.

[sasview-bot]

Trac update at 2018/07/10 10:08:28:

• tcbennun changed attachment from "" to "structure_tab_mockup.png"
• tcbennun commented:

A (probably highly unrepresentative) early version of a dedicated S(Q) tab in the QT GUI

[sasview-bot]

Trac update at 2018/07/10 10:14:53: tcbennun commented:

The idea presented in the screenshot above is to have a single S(Q) tab, and if there are multiple S(Q)s used they are grouped under headings in the tree view. The layout will likely look more similar to the Polydispersity tab (larger boxes, single-click to edit, combo-boxes are clear '''before''' clicking, etc.) after some tweaking.

The actual text in the boxes is mostly meaningless right now, though. :)

This code is in the branch ESS_GUI_iss959 (issue 959 is the JIRA issue for this).

[sasview-bot]

Trac update at 2018/07/24 14:36:16:

• tcbennun changed _comment0 from "Shelving this for the time being, to focus on the approach in incorrect default for rectangle dispersion (Trac #1060) #1116 http://trac.sasview.org/ticket/1116 instead." to "1532443001260331"
• tcbennun commented:

Shelving this for the time being, to focus on the approach in #1161 instead.

• tcbennun changed milestone from "SasView Next Release +1" to "SasView 5.0.0"

[sasview-bot]

Trac update at 2018/09/09 07:49:55:

• tcbennun commented:

The approach taken currently is to include S(Q) options in the main parameter table, as this is tidy and does not introduce further GUI options for the user to be confused about.

Such functionality is now available in the ESS_GUI branch, when sasmodels branch beta_approx is in use.

• tcbennun changed resolution from "" to "wontfix"
• tcbennun changed status from "new" to "closed"