Multiplicity models do not appear in drop-down in Custom Model > Sum|Multi

[smk78]

Reported by Saeed Mohan (saeed.mohan@…):

I was attempting to add in my own custom model to Sasview, which is based on the UnifiedPowerRg model. I thought the easiest thing to do would be to use the Sum Multi|(p1, p2) function under Fitting > Edit Custom Model, however I am not able to find this model in the options list.

Checked by SMK. He is correct.

What is more, the same bug exists in v3.0.0 and v2.2.1!!!

PDB checked and it appears that no multiplicity models appear in the dropdown (eg. RPA10, onion, etc). This is probably working as designed since I suspect the interface was not obvious for a multiplicity model? Interestingly there is also a very strange behavior that the shape independent → Absolute_Power_Law seems to have been renamed in this dropdown to PowerLawAbsModel … perhaps due to the space in the name?

[butler]

The way this is currently handled is in ModelManagerBase in models.py. every model is explicitly added to a variety of lists and dictionaries. The sum model dropdown uses the model_name_list to populate itself. ModelManagerBase has two mutually exclusive lists: model_name_list and multi_func_list. This last is the list of all models which have a multiplicity parameter (selectable number of levels). One CAN force these to also be members of model_name_list but the sum model editor will then only produce a sum model with 1 level as there is currently no way to select that. This would require a GUI change in src.sas.perspectives.calculator.model_editor.TextDialog to handle.

We will have to deal with this as part of sasmodels.

[butler]

with regard to the naming issue it appears that the sum model editor uses the file name (PowerLawAbsModel.py) while the fit panel's drop down uses the self.name parameter of the model. These seem to usually be the same or similar except in the PowerLawAbsModel which is alphebetically far away from the otherwise first Absolute Power_Law.

The GUI should be consistent and always use one or the other. This should be addressed as part of the new sasmodels implementation as well though it may be appropriate to divide these into two tickets