Bug in WeightedOptimizerEngine Uniform sampling method number of points

[flongford]

In order for any KPI results to be produced from the WeightedOptimizerEngine.optimize routine using "Uniform" space sampling, the num_points attribute must be larger than the number of KPIs. Additionally, setting num_points=1 will cause a ZeroDivisonError to be raised here: https://github.com/force-h2020/force-bdss/blob/master/force_bdss/mco/optimizer_engines/space_sampling.py#L140

The description of the num_points attribute here isn't clear - it should refer to the number of weight combinations used in a grid search for each KPI. Therefore we would expect that setting num_points=2 would sample over 2^(no. KPIs) grid points.

However, the WeightedOptimizerEngine does not actually use any combinations of weights that contain zero values. Therefore only a subset of the full possible range of combinations is used, and since the sum of weight values must be normalised, this is not possible while num_points <= len(kpis).

Proposed solutions

• [ ] We should set the minimum allowed value for the num_points attribute as 2, so as to avoid the ZeroDivisionError

• [ ] We should also implement a more intuitive API (maybe exposing a different grid search parameter instead) so that it is more clear what is going on in the backend.

[sparsonslab]

• are min/max's an in-built functionality of traits (that might give an out-of-range message), or would we have to put that in (easy enough)?

• this brings up a general issue with workflow/bdss: whenever the user puts in an improper value (in either a workflow file or the UI) all they get back (invariably) is a little error dialog with something like "user stopped bdss" (no I didn't!) or part or the workflow tree is blocked out. It never gives any indication of what might be wrong. Of course this is a problem of software the world over!

[flongford]

• are min/max's an in-built functionality of traits (that might give an out-of-range message), or would we have to put that in (easy enough)?

Typically not, this tends to be a feature that is controlled in the UI using TraitsUI editors. However, an example of a modified Trait that has a similar functionality is the PositiveInt. You can see that the TraitType.validate method is over written to achieve this.

• this brings up a general issue with workflow/bdss: whenever the user puts in an improper value (in either a workflow file or the UI) all they get back (invariably) is a little error dialog with something like "user stopped bdss" (no I didn't!) or part or the workflow tree is blocked out. It never gives any indication of what might be wrong.

I have noticed that too - the "User stopped BDSS" pop up is a recently introduced feature in the force_wfmanager, so I expect that there is a bug with this dialog appearing instead of an error message when things go wrong.