Opened 5 weeks ago

Closed 4 weeks ago

#1134 closed defect (invalid)

sum/multi scale factor in 4.2 seems incorrect?

Reported by: richardh Owned by: pkienzle
Priority: blocker Milestone: SasView 4.2.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing


With Torin watching me, I just downloaded installer for 4.2, build #1279 from Jenkins.

Repeated the test of   ellipsoid*hardsphere  , comparing plugin produced by  sum/multi  with normal P*S as per the projects I uploaded at #1118

The "scale" factor in sum/multi is not correct, seems to be tied to the volume fraction in the S(Q) when it should not be.

Attachments (2)

PS_test5_default_model.png (115.7 KB) - added by richardh 4 weeks ago.
default P(Q)S(Q)
PS_test5_plugin_model.png (113.9 KB) - added by richardh 4 weeks ago.
v4.2 plugin multi P(Q)S(Q)

Download all attachments as: .zip

Change History (7)

comment:1 Changed 5 weeks ago by butler

OK …. sorry it took so long but I finally had a few hours to look through the posts, the projects and tests. I believe sum|multiply is behaving exactly as advertised which is what was agreed after long debate at the SNS code camp. The question I think is whether that should be revisited.

Fundamentally sum|multiply is meant to be a generic (i.e. rather dumb) way for users to easily concatenate models without having to write the code to call one then the other (or worse, write a full new model from scratch which is a simple combination of existing models). It makes no assumptions about models or what the user is trying to do with them. S * P on the other hand is meant to provide a GUI way to more intelligently address the specific case of multiply models (not add) of a form and a structure factor. Thus in THIS GUI (and only this GUI) the UI has to know which is a P and which is an S and if the given P can in fact be multiplied by and S and includes "intelligence" like knowing that the vol fraction and ER could be related between the two functions etc.

Regarding the scale factor not being one, that is because it should not be. It is the vol fraction applied to the form factor (which scales everything up and down) while vol fraction is a specific parameter of S(Q) which scales the position and sharpness of the interaction peak but NOT the scale of the curve.

In some sense then Sum|multiply provides the case where the SQ eff radius and eff vol fraction can be made to vary independently of those of the form factor.

As I understand it, in sum|multiply, ALL the parameters of each model are available independently (they are NOT tied to each other in any way as the options become nearly limitless) and the scale and background, which are not part of the models any more, are added as described. For multiply the scale factor multiplies with the two models and then a background term is added while for + a scale factor is provided for each model so they can be added in different ratios, then that entire sum is multiplied by a scale factor and finally a background is added (which is not multiplied by scale). I note that the description for sum currently fails to mention the scale factor for each model - that needs to be fixed assuming we keep the current structure.

Anyway that is how I understand the current situation - which is pretty much what I remember us discussing in Oak Ridge?

comment:2 Changed 5 weeks ago by smk78

Confused now!

@richardh seems to be saying 'scale' and 'vol_frac' are tied; @butler seems to be saying they are not (or at least should not be)?

Certainly I have seen Users fixing 'scale' when they turn on S(Q) and get the 'vol_frac' parameter to play with…

comment:3 Changed 5 weeks ago by butler

Good point. Need to check with @richardh but my understanding is that by ¨ẗied¨ he means that the fit to essentially the same value … as they would have to be from my understanding of sum|multiply assuming that the SLDs are set correctly. That is what I see also when I try it.

Changed 4 weeks ago by richardh

default P(Q)S(Q)

Changed 4 weeks ago by richardh

v4.2 plugin multi P(Q)S(Q)

comment:4 Changed 4 weeks ago by richardh

Sorry, perhaps I have not explained well enough. Have added my two screen shots here again, they are for the same data with the same models, so should have the same scale parameter.

The screen shot for the "default" P(Q)S(Q) has been fit with an sld adjusting so as to force "scale" to 1.0 for ease of comparison.

Now compare the screen shot for the v4.2 plugin model, it indeed has P(Q) and S(Q) parameters entirely separate as expected. The effective radius in S(Q) is fixed here at the correct computed value. The sld's are also the same, and the flat background fits to the expected value. So the leading scale factor ought to come out at 1.0, but for some reason it is fitting to the same value as volfraction in S(Q).

Somewhere in all the special cases for volfraction and scale parameters I think some manipulation of "scale" has happened, I am still working on finding out where this is, or rather I have enlisted some help from Torin. (If the intention was to include volfraction from S(Q) in the leading scale as part of the absolute intensity of P(Q), then the original scale should perhaps have been divided by volfraction, not multiplied by volfraction.)

comment:5 Changed 4 weeks ago by richardh

  • Resolution set to invalid
  • Status changed from new to closed

Perhaps I have been a little slow here again, it is the original default P(Q)S(Q) that is confusing (as usual), in that it does include volfraction from S(Q) in the absolute intensity of P(Q).

Thus in my example for the new mixture model having scale come out the same as volfraction is actually OK.

Silly me,

I will close the ticket.

Note: See TracTickets for help on using tickets.