CURRENTLY

When SasView is launched all models are loaded and assigned to a variety of lists and dictionaries in models.py (mainly in the _getmodellist method). These list seem somewhat redundant but are used in a variety of places and refactoring this may not be what we want to do at this time.

Lists

• The following two lists were excised during the fixing of category manager but remain in commented lines (including chunks of code in other modules that used these list which were rewritten but the old code is there with a PDB and date comment — they should probably all now be removed.
  • shape_list
  • shape_indep_list
• strut_list
• multiplication_factor
• P(Q) models are assigned to either one exclusive OR the other of these two lists (these are used in the sum model editor for example to only allow models that do not have multiplicity)
  • model_name_list
  • multi_func_list
• model_combobox=ModelList

Dictionaries

• model_dictionary
• form_factor_dict
• struct_factor_dict

NOTE: For models that support orientation or magnetic SLD calculations, the model is queried for the existence of a model.orientation.params and model.magnetic_params() list that is have lengths greater than zero. As long as we don’t change that we are ok. Otherwise there will be some work to find where all in the GUI it is called.. Also as discussed for the beta approximation OR for the ability to create complex models we would need access to Fq so should we provide an attribute for that?

Independently category manager reads serialized_cat.json file from the user directory (or default_category.json from distribution if former does not exist) and creates: master_category_dict (where category is the key) and dependent dicts: by_model_dict(where model is the key) and model_enabled_dict it then checks the list of models created by models._getmodellist and compares to its own list. If a model exists for which there is no entry in the master_category_dict it is added and assigned the category “uncategorized.”

PROBLEM: while shape and shape independent have been de-entwined struct is still hard coded AND remains a category I think. Thus presumably removing structure as a category could cause issues. Basically there remains a fundamental coupling between the SasView specific GUI needs and the sasmodel computational code.

PROPOSAL

We should completely decouple categories (shape, gel, polymer, cylindrical etc) from model attributes (structure factor, contains layers = multiplicity, can be multiplied with a structure factor, has 2D? mag? F(Q) for beta approximation? etc). The first is a SasView GUI specific concept to allow the user control of how the models are organized in their personal GUI. The second is needed by any user of sasmodels to understand what/how the model can be used. Thus the model should provide a way to discover what computational features it supports/needs (multiplicity, structure factor, etc). This could be by providing a method that returns a list of all attributes which calling code can then query that tests for the existence of an attribute (eg. multi) in the returned list. Alternatively they could just be a list of attributes which can be tested for with a try except. Beyond that I see two option:

OPTION I

• Replace _getmodellist to read all current models (either just name and attributes or loads model - 2 be discussed). Creates appropriate lists and assigns models based on model attributes.

ADVANTAGE:

• cleanly decouples SasView and GUI from sasmodels and computation
• simplest changes to current code — all category code stays intact.

DISADVANTAGE

• More work required by developers for models to be distributed with release in that they should edit the default.json to assign a default category to their model.

OPTION II

• Replace _getmodellist to read all current models (either just name and attributes or loads model - 2 be discussed). Creates appropriate lists and assigns models based on model attributes.
• Add a default_category attribute to each model
• Edit category code so that for any models in the list generated by _getmodellist that are not in the category file it first queries the model for the default category. If that fails only then fall back to assigning to “uncategorized.” It will remain in that category until the user moves it to where they prefer.

ADVANTAGE:

• Less work required by developers for models to be distributed with release as they will not need to edit the default.json to assign a default category to their model.
• User created/distributed models will have a default category.

DISADVANTAGE

• Introduces (leaves) some cross-over between SasView GUI specific items and the sasmodels computational code.
• More parts of the current code implementation need touching..

NOTE 1: Do we want models to continue to provide a list attribute of orientation and magnetic parameters using the same names as currently (minimum work) or is there a more clever way to handle them. This last will require some GUI refactoring but should be doable I think with some search functions and testing but will definitely be work.

NOTE 2: The existence of ER and VR methods is not currently required. However, computationally they are required in certain circumstances which should match certain flags/attributes. For example I believe that any model that can be multiplied by a structure factor will need the ER method. QUESTION: do we enforce all models to have the method? or do we use the existence of the method to determine if the model can be multiplied by a structure factor? or leave the redundancy as is and hope we never get someone putting in a model with a flag indicating it can be multiplied but forgetting to provide the ER method?