control order in which fit parameters appear in gui

[richardh]

Suspect that the current “almost alphabetical” order for most but not all models is an “accident” due to python dictionaries.

\models\c_extension\python_wrapper\WrapperGenerator?.py, ~line 328, routine write_c_wrapper produces a python type dictionary by:

for par in self.params: param_str += "

PyDict_SetItemString(self→params,\"%s\",Py_BuildValue(\"d\",%10.12f));\n" % \ (par, self.params[par])

The main parameter dictionary may then have the polydispersity parameters added on to it. Alas python dictionaries are assembled in random order due to use of hash tables.

When a model is loaded “param_list” is acquired via

\sas\models\BaseModel?.py, ~line 125.

def getParamList(self):

param_list = self.params.keys()
return param_list

[Note that many other places have similar routines for other parts of sasview.]

Would it be possible to use an ordered dictionary, in order to keep parameter in a particular order, such as the order in which the default values appear.

Paul Kinsell warns that there will be consequences for the way he passes parameters to fitting routines.

[butler]

This while be a lot of work in current framework and unlikely to be achieved in time and while a very nice addition not critical for a release. Further there is a real question of whether it won't just be easier as part of sasmodels project. Thus moving to next release for now. Then we can discuss best course of action

[butler]

This should be part of the new sasmodels work. It may be a duplicate of #361 but may be best to think of this as the SasView GUI interfacing to the new sasmodels properly while ticket #361 refers to building the new sasmodels in a way that makes it easier for the GUI to do this.

Either way it should be part of one of the 6 core tasks for this release so making it blocker.

[butler]

Once all models are converted, suggest Richard look at the order and make sure it makes sense from a user perspective?

[gonzalezm]

Solved for single models only.

[ajj]

Miguel has fixed this for single models from sasmodels i.e. not easy sum/multi.

Closing this as "good enough for 4.0" and will open lower priority tickets for sum/multi and user provided models.