Passing additional computed, non-fitting, parameter values back from models

[richardh]

Would be good for constraints on S(Q) radius and phi to be able to access ER and VR values from preceding P(Q) model, preferably without making models too much more complicated. Likely more than one possible type of ER, see #780 and #1115.

Would be good for some models to return usful information to users, e.g. Debye lengths from hayter_msa S(Q).

Paul K says that this might not be simple, but he has some ideas.

[pkienzle]

Some issues:

(1) don't want to calculate these values during fits unless they are needed

(2) some of these values (e.g., ER) will be evaluated over parameter distributions

(3) how should these values be displayed in the user interface?

Should be able to set up a new type of parameter in the parameter table as a derived value, giving it a name, units and description. There will be no limits or default. Could set the type to be 'derived', and set 'limits' as the function, much like limits=[OPTION_LIST] is used for a list of options.

The function needs to accept a parameter table with parameter values and weights. If called with a distribution of values, then the average will need to be returned. Unlike the current ER call the complete parameter table may be needed, depending on what is calculated, not just the volume parameters. Passing the call details and parameter values vector to the function wrapper would give enough information.

Need to update DirectModel?, BumpsModel? and SasviewModel? to prepare the inputs and call the function when the parameter value is requested. Need to update the mixture model and product model to break the parameters into parts for the individual functions. There is a risk of circularity: if parameter a depends on ER which depends on parameter b, we can't request ER without triggering a request for a. The solution should avoid repeating the expensive operation of setting up and tearing apart the parameters for the function call.

[tcbennun]

The sasmodels branch beta_approx_new_R_eff contains functionality to pass back the computed ER, as detailed in #780. However, this mechanism is not generic, so new code needs to be added into the kernel and surrounding architecture, e.g. generate.py, for any new computed quantities to be passed back.