Unclear intended use of controller-object

[AndreasHempel]

The documentation for optimizerFORCES states that the returned controller object should be called with the parameter values:

solver = optimizerFORCES(...);
x = solver{paramValues};

It is not specified (and does not seem to matter much) whether paramValues is a list of parameter values (used in mpc_parametric_dynamics.m):

[U(:,k),exitflag,info] = controller{ X(:,k), A, B };

or a cell array with the parameter values (used in mpc_parametric_cost.m):

[U(:,k),exitflag,info] = controller{ {X(:,k), Q,R,P} };

The generated solver on the other hand requires the parameter values to be provided in a cell array and will complain when provided with a list of parameters.

What is the intended use of the controller object?
On the one hand, for consistency it would be great to call controller the same way you would call solver. This would require cell arrays also for the controller object, but for problems with a single parameter, e.g. the simple MPC example, the notation controller{ {x0} } is not so nice.
On the other hand, having both calling conventions for the controller object will probably lead to errors and confusion down the line. The controller object is not persistent after all and requires the entire code generation to run again, there is not way to create a controller object for a previously generated solver (or is there?).

Thoughts?

[GianUlli]

The interface of the controller object (i.e. an instance of the class optimizerFORCES) was designed to mimic the interface of YALMIP's optimizer function, e.g. see https://yalmip.github.io/optimizerupdates/ for an explanation of the (updated) interface. This should make it easier to switch from a generic solver to FORCES Pro in an existing implementation using YALMIP. I tried to make the documentation of optimizerFORCES more specific with commit 030a178.

Using an already generated solver after the controller object is lost is still possible through the MEX interface. This interface does not offer the "versatility" of the controller object, in that it can only be called using a cell array containing the parameter values. I think it makes sense, that the MEX interface expects a specific kind of input, since accepting different kinds (list of parameters AND cell arrays) would slow it down. If that input should be a cell array (as it is at the moment) or a list of parameters is not clear.

The usage of the MEX interface is currently not mentioned in the documentation of optimizerFORCES. We should add a note there.