Sum/Product Models don't do what they should

[smk78]

The Sum|Multi model generator is not creating properly parameterised models:

Sum
Should do: scale_factor * {(scale_1 * model_1) + (scale_2 * model_2)} + background

Is doing : scale_factor * {(scale_1 * model_1 + background_1) + (scale_2 * model_2 + background_2)}

Product

Should do: scale_factor * model_1 * model_2 + background

Is doing : (scale_1 * model_1 + background_1) * (scale_2 * model_2 + background_2) + background

[butler]

Is this really a blocker? Obviously the change would be much cleaner but not sure it is a blocker. By appropriate choices of values for scales and background the expected behavior can be achieved, just a bit …. ugly!

[smk78]

Except no user actually knows that…

[butler]

Welll… funny you should say that:-) Actually I would argue it will be quickly obvious to most "ordinary" users and that the people who will be most confused will be us, the developers. Indeed we have been talking so long about what we want it to be but cant keep track in the flurry of activities what has and has not been done that we (at least I do) get confused.

In fact, the very title of the ticket is incorrect. Sum and multiply do EXACTLY what they say. In fact the statement of the problem is a bit misleading. For example for the sum model it says:

Is doing : scale_factor * {(scale_1 * model_1 + background_1) + (scale_2 * model_2 + background_2)}

But really what it is doing is exactly what it says when you create the model namely:

Scale_factor * (Model_1 + Model_2).

All the parameters of model 1 and all the parameters of model 2 are present (and labeled as 1 or 2) and a separate non numbered scale factor is added. If the model in question has a scale and/or a background then it/they will show up, and if not (try for example hard sphere as one of the models) it/they won't. An ordinary user might asks us: what part of model_1 don't you guys understand? For me it would be the fact that when writing models I don't usually include scale and background anymore which are auto added (or not as the case may be), but an ordinary user will likely not be so encumbered by prejudice

That said I think we should change the behavior as soon as we can as suggested in the ticket. I am just worried that we may not have the bandwidth to get it done soon enough for a release and questioning the priority of this particular ticket.

[butler]

ooops my bad. While last comment I think is correct, my previous one is not entirely so. Mainly for a sum model there is no way to decouple scale(time del rho etc) from background.

[ajj]

Checked current master. Changed name of ticket to reflect real nature of ticket.

This should be fixed as the behaviour is a pain - all the multiplication of backgrounds and the "BackGround" parameter with inconsistent capitalisation is horrid.

Should probably be replaced by something nicer in sasmodels that can properly cope with more arbitrary model arithmetic, but behaviour could also be fixed in current implementation with suppression of background parameters etc.

Not a blocker for 4.1

[ajj]

The model arithmetic should make use of the tools in sasmodels that Paul K has worked on.

[lewis]

The sasmodels code for this was merged into master in commit ​b18e650

[smk78]

The documentation for custom models will probably need updating too. Now if a user creates a sum/multi model, a file that looks like the one below will be created in the plugin_model directory:

from sasmodels.sasview_model import make_model_from_info
from sasmodels.core import load_model_info

model_info = load_model_info('sphere+cylinder')
model_info.name = 'MyModel'
Model = make_model_from_info(model_info)

By changing the string that's the argument to the load_model_info function, the user can change the model. Any combination of model names, + and * will work. The use of brackets isn't supported, and operations will be executed in the correct order (i.e. multiplication first, then addition). Custom model names can also be used in the model string by prepending the model name with 'custom.', e.g. sphere+custom.MyModel

Structure factor models can also be created using the @ symbol, e.g. cylinder@hardsphere

[smk78]

Lewis' Ticket-767 branch has now been merged to master and the docs updated so I am closing this ticket.

Related ticket 861 (and associated pull request 104) could do with a second review just in case there is a sasmodels dependency that has been missed.