Opened 5 months ago

Closed 2 months 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)

structure_tab_mockup.png (19.9 KB) - added by tcbennun 4 months ago.
A (probably highly unrepresentative) early version of a dedicated S(Q) tab in the QT GUI

Download all attachments as: .zip

Change History (7)

comment:1 Changed 5 months ago by richardh

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.

comment:2 Changed 5 months 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 5 months 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 4 months ago by tcbennun

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

comment:4 Changed 4 months 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 4 months 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.

Last edited 4 months ago by tcbennun (previous) (diff)

comment:6 Changed 2 months 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.

Note: See TracTickets for help on using tickets.