-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add volume fraction explicitly in all relevant models (Trac #475) #609
Comments
Trac update at
|
Trac update at |
Trac update at
Moving back to 4.0 as part of ticket #775 admonition to finalize parameter and model names so as to remain compatible in the future. Does this come under that heading?
to:
|
Trac update at
I think(?) that we have been talking around this issue during discussion of the beta approximation. The pros and cons were left mostly at the con level so far: having yet another parameter on the screen to deal with which is completely correlated to the scale factor seemed to override the elegance of separating an arbitrary scale factor (data not on absolute scale) from the volume fraction and thus making it explicit for the user what "scale" is (we get lots of questions on that despite trying to put that in the documentation). Now that we are focussing on composite models of various sorts it may be time to revisit this question? At any rate will move this to the beta approximation work package for now.
|
Trac update at The default P(Q)S(Q) is one case where volfraction (from S(Q) ) is included in the absolute intensity, and we have a separate "scale". The same P(Q)S(Q) generated as a plugin model by sum/multi has a single "scale". Perhaps we should call the parameter "scale_volfraction" when there is only one of them, and "scale" and "volfraction" when there are both???? |
Trac update at I would suggest it would be better to re-label them the other way: keep ''scale'' as is, but change ''volfraction'' to ''SQ_volfraction'', or similar. It would be less disturbance to the docs... |
Trac update at Yes, i had thought likewise, but we need to make it clear how the absolute intensity is derived. Torin already has an idea to insert sub-headings with the actual model names into the parameter list in 5.0, so it will be more obvious which parameters relate to which P(Q) and/or S(Q) without having to modify their names, and with the insertion of brackets around the sub-headings, even the order of more complex calculations. |
Trac update at |
Trac update at |
Trac update at Need to be careful with F(q) and calculation of beta approximation. Vf should apply after beta:
but within the current infrastructure the Vf parameter needs to be processed within the call to F(q). For the purposes of the beta approximation, we must return Incorporating sqrt(Vf) into F may cause difficulties for future uses of F; it may also be confusing to users who are expecting that F should equal 1 at q=0, but they will already be confused by the presence of the contrast term with within the calculation of F. |
Trac update at Is this linked or separate from working in absolute units? Otherwise a radio button stating "data is in absolute units; scale is volume fraction" might be an option? I know it is not strictly necessary for the volume fraction in a structure factor calculation... |
11 November 2015 23:19
Subject: Re: [!SasView] Ticket #606: reparameterize Teubner-Strey
Wonder if what we want to do ...eventually - don't think we want to muddy waters right this minute (could be for code camp?) but maybe we want to add phi explicitly in all the models where it comes in. This might help reduce confusion in that scale will then always be one except to fix normalizaition problems (no abs scale or the phi and slds chosen and fixed by user are wrong). It would add a parameter to the GUI but at least it would then be consistent across all models?
Paul
Migrated from http://trac.sasview.org/ticket/475
The text was updated successfully, but these errors were encountered: