Skip to content
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

Open
smk78 opened this issue Mar 30, 2019 · 11 comments
Open

Add volume fraction explicitly in all relevant models (Trac #475) #609

smk78 opened this issue Mar 30, 2019 · 11 comments
Labels
Enhancement Feature requests and/or general improvements Major Big change in the code or important change in behaviour

Comments

@smk78
Copy link
Contributor

smk78 commented Mar 30, 2019

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

{
    "status": "new",
    "changetime": "2018-09-08T13:10:28",
    "_ts": "2018-09-08 13:10:28.941782+00:00",
    "description": "11 November 2015 23:19\nSubject: Re: [!SasView] Ticket #472: reparameterize Teubner-Strey\n\nWonder 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?\n\nPaul",
    "reporter": "smk78",
    "cc": "",
    "resolution": "",
    "workpackage": "Beta Approximation Project",
    "time": "2015-11-17T16:39:28",
    "component": "SasView",
    "summary": "Add volume fraction explicitly in all relevant models",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView Next Release +1",
    "owner": "",
    "type": "enhancement"
}
@smk78 smk78 added this to the SasView Next Release +1 milestone Mar 30, 2019
@smk78 smk78 added Beta Approximation Project Enhancement Feature requests and/or general improvements Major Big change in the code or important change in behaviour and removed Incomplete Migration labels Mar 30, 2019
@butlerpd
Copy link
Member

Trac update at 2015/11/21 04:37:07:

  • butler changed milestone from "WishList" to "SasView 4.0.0"
  • butler changed workpackage from "SasView Fitting Redesign" to "SasModels Redesign"

@butlerpd
Copy link
Member

Trac update at 2016/08/16 14:21:16: butler changed milestone from "SasView 4.0.0" to "SasView Next Release +1"

@butlerpd
Copy link
Member

Trac update at 2016/09/05 03:29:44:

  • butler commented:

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?

  • butler changed description from:

11 November 2015 23:19
Subject: Re: [SasView] Ticket #472: 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

to:

11 November 2015 23:19
Subject: Re: [!SasView] Ticket #472: 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

@butlerpd
Copy link
Member

Trac update at 2018/07/04 18:36:29:

  • butler commented:

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.

  • butler changed workpackage from "SasModels Redesign" to "Beta Approximation Project"

@RichardHeenan
Copy link
Contributor

Trac update at 2018/07/23 15:13:22: richardh commented:

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????

@smk78
Copy link
Contributor Author

smk78 commented Mar 30, 2019

Trac update at 2018/07/23 15:39:30: smk78 commented:

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...

@RichardHeenan
Copy link
Contributor

Trac update at 2018/07/23 15:58:13: richardh commented:

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.

@sasview-bot
Copy link

Trac update at 2018/07/24 13:01:55: tcbennun changed attachment from "" to "param_subheadings.png"

@sasview-bot
Copy link

Trac update at 2018/07/24 13:06:51: tcbennun changed attachment from "" to "image001.png.png"

@pkienzle
Copy link
Contributor

Trac update at 2018/09/06 15:37:59: pkienzle commented:

Need to be careful with F(q) and calculation of beta approximation. Vf should apply after beta:

beta = <F>^2/<F^2>
I = Vf (<F^2> + beta*(S - 1))

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 sqrt(Vf)*<F> and Vf*<F^2> to apply within the calculation of F and F^2^ so that it cancels in calculation of beta. This is done within the vesicle model, for example.

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.

@sasview-bot
Copy link

Trac update at 2018/09/08 13:10:28: toqduj commented:

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Feature requests and/or general improvements Major Big change in the code or important change in behaviour
Projects
None yet
Development

No branches or pull requests

6 participants