COSMO & conflicting hard constraints?

[B-LIE]

One of my students is using COSMO as a back-end to JUMP to solve a discrete optimal control problem. The model is linear, the cost function is quadratic, and there are two hard constraints on outputs:

• One hard constraint is on the grid frequency (it is a hydropower model) -- the frequency is required to satisfy 50+/- 0.1 Hz
• One hard constraint on the rate-of-change of produced power -- it is required that -p_ <= P_ <= p_, where P_ is the rate of change and p_ is the bound.

-> If he removes the constraint on rate-of-change of produced power (p_ -> very large), COSMO satisfies the frequency constraint.
-> If both constraints are included, COSMO finds a solution that breaks the frequency constraint (possibly also the rate-of-change of power constraint).

QUESTION: how does COSMO handle cases where there is no feasible solution (like here) -- is it meant to report back that there is no feasible solution and then stop, or will it for that case produce an approximate solution? (IPOPT finds an approximate solution by default).

[goulart-paul]

The solver should return a status indicating that the problem is (primal) infeasible. In that case it will still return solution vectors, but the "solution" will instead be a proof of infeasibility for the problem in the form described in section 2.1 of the paper here.

See also the documentation section on infeasibility here.

[B-LIE]

Thanks for super quick response.

In the current case, the hard constraint that is broken is only marginally broken.

• Could it be that the default tolerance (if this can be specified) allows for some slack on the contraints?

[Alternatively, could JUMP have some strategy? I should probably ask the JUMP people about that...]

[goulart-paul]

The solver has settable tolerances that determine the stopping criteria. If your constraints are almost satisfiable, i.e. it is possible to produce an iterate where the residuals of the KKT conditions are very small even if those conditions are not actually satisfiable, then the solver may return such a point and claim it is optimal.

All of the solver parameters are described here, and all are settable via JuMP. The default tolerances are relatively loose since the solver uses a first-order method, but you could try tightening them up a bit. The relevant ones for declaring a point optimal are eps_abs and eps_rel. There are also eps_prim_inf and eps_dual_inf, which determine the point at which the solver will declare that it has found a proof of infeasibility. Maybe try tightening those to 1e-6 to start.

You probably don't want to make them too tight since a first order method will typically not coverage to very high accuracy quickly. If you want something more like 1e-8 type accuracy, then perhaps better to use an interior point method. We are partial to this one.

[B-LIE]

Thanks a lot for quick answers!

[goulart-paul]

No problem. I will close the issue since we have (I hope) answered the question, but feel free to reopen if needed.