To see how such a problem is modeled in YALMIP, a unit commitment example is now available.

If you would like to see how additional constraints or logic behaviour can be added to the model, let me know!

How it used to work

Consider for instance the trivial problem minimize {$x$} subject to {$x \geq b$}. Let us assume we want to solve this problem for different {$b$}. Computing the solution for this problem for a range of {$b$} between 0 and 1 using optimizer would be coded as

Effectively, when the optimizer command is called, YALMIP treats {$x$} and {$b$} as decision variables, detects it as a linear program, and returns a precompiled numerical object for this linear program. When this object is indexed with a value {$b_{trial}$}, an equality constraint {$b = b_{trial}$} is easily added to the precompiled model and the selected solver is called.

Now, consider the minimize {$x$} subject to {$ax \geq 1$} instead. Here, the varying parameter is {$a$}. If YALMIP is asked to precompile this model, it will not detect a linear program since it is bilinear in {$a$} and {$x$}. Instead, it will treat this as a general nonlinear program, and return a precompiled numerical object for such a solver. When the optimizer object command is called for evaluation with a particular value, adding the equality constraint {$a = a_{trial}$} will still leave us with a bilinear program, which would be solved using the selected nonlinear solver.

How it works now

To support these more general models, two changes have been introduced. To begin with, an equality constraint is no longer added the the precompiled models unless the parameter enters affinely. Instead, the parameter {$a$} is now replaced with the given value. Simple as it sounds, on large complex models, this can actually be rather complicated, since the precompiled model is described in a very dense numerical format.

In our model above, if we replace {$a$} with a fixed value, the final model is obviously an LP, and an LP solver should thus be used. However, if YALMIP is allowed to select solver when calling optimizer, it will still select a nonlinear solver, as the code for compiling the optimizer object currently shares its core with solvesdp, which of course treats all variables as decision variables. However, we can circumvent this by forcefully telling YALMIP which solver to use, despite the fact that it does not support the problem class YALMIP thinks the model is. This is why the feature still is considered to be in a beta stage. To forcefully select a solver, a + is appended to the solver name.

Limitations

At the moment (this list changes over time)

• In nonlinearly parameterized problems, you must specify the solver.
• Terms in a cone operator can not be nonlinearly parameterized (easily cirumvented by in introducing a new variables, i.e., instead of cone(a*b,c) where a is parameter and b is a decision variable, use cone(u,c) where u is a new decision variable constrained by u==a*b)
• Terms inside nonlinear operators (such as min/max/norm) cannot be nonlinearly parameterized. The same trick as above can be applied here to of course.