Opened 6 years ago
Closed 6 years ago
#1115 closed enhancement (wontfix)
qt5 user level S(Q) tab
Reported by: | richardh | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | SasView 5.0.0 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | Beta Approximation Project |
Description
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 ….
Attachments (1)
Change History (7)
comment:1 Changed 6 years ago by richardh
comment:2 Changed 6 years ago by richardh
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?
comment:3 Changed 6 years ago by richardh
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.
Changed 6 years ago by tcbennun
A (probably highly unrepresentative) early version of a dedicated S(Q) tab in the QT GUI
comment:4 Changed 6 years ago by tcbennun
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).
comment:5 Changed 6 years ago by tcbennun
- Milestone changed from SasView Next Release +1 to SasView 5.0.0
Shelving this for the time being, to focus on the approach in #1116 instead.
comment:6 Changed 6 years ago by tcbennun
- Resolution set to wontfix
- Status changed from new to closed
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.
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.