Opened 8 years ago
Last modified 6 years ago
#871 new defect
autogenerated plot in doc for rpa is not helpful
Reported by: | butler | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | SasView 4.3.0 |
Component: | sasmodels | Keywords: | |
Cc: | Work Package: | SasModels Infrastructure |
Description
The autogeneration of an example plot in sasmodel documentation based on default parameters is quite useful normally, it can be problematic for multiplicity models where all the parameters of the multiplicity have the same value. In particular the rpa has scattering length of each component as a multiplicity parameter so all are set equal to the one default. Unfortunately that means that I(Q)=0 at all Q. It would be nice if we could get a sensible plot in such, admittedly rare, cases.
Change History (4)
comment:1 Changed 8 years ago by pkienzle
comment:2 Changed 7 years ago by butler
- Milestone changed from SasView 4.2.0 to SasView 4.3.0
comment:3 Changed 6 years ago by butler
- Work Package changed from SasModels Redesign to SasModels Infrastructure
comment:4 Changed 6 years ago by smk78
Also see attachments in #1261
Note: See
TracTickets for help on using
tickets.
(1) Accept vector values for parameter defaults so you can provide an interesting default parameter set.
The doc generator will need to know how to format parameter lists.
(2) Use the "demo" parameter set for the doc plot. We can remove demo parameters for all models that have reasonable defaults, which is to say most of them. Demo already supports vector parameters:
The doc generator will need to include a nicely formatted list of parameter values that are not the default value as part of the figure caption.
(3) Give the user direct control over the sphinx layout of the parameter table. This would allow us to define the table using sasview 3.x parameter names while still having a compact table representation:
(4) Allow the parameter table to be manipulated after construction. We should probably do this anyway since it is pretty trivial and provides a lot of flexibility. The result would look something like:
We could then rename the user parameters from N1,N2,… to Na, Nb,… using:
This approach will be somewhat brittle. Any changes to the internal data structures will require all affected models to be updated. The doc generator won't know how to handle an arbitrary manipulation of the internal data structures, so this would need to be in combination with option (3).
These options are not exclusive. That is, we may want to have independent control of the default values on vectors while using the demo values to generate the default plot while allowing the user to override the parameter table while allowing direct manipulation of the underlying ParameterTable data structure.