Support calling solver functions other than nlpsol #1007

Closed SGeeversAtVortech closed 2 weeks ago

In GitLab by @vreeken on Feb 27, 2018, 17:15

Currently, we can only call ca.nlpsol, with no way to override this behavior. Some common commercial solvers (like Gurobi and CPLEX) only support at most (MI)SOCP, and are therefore not part of the list of solvers available with ca.nlpsol. So it would be nice if the user could easily (and user-friendly) override the CasADi solver function that is being called, e.g. ca.qpsol (with clp as solver).

In GitLab by @baayen on Mar 23, 2018, 15:16

We will want to consider the following categories of optimization problems:

Problem category	Package	CasADi solver function
Linear programming	CPLEX, Gurobi	`qpsol`
Quadratic programming	CPLEX, Gurobi	`qpsol`
Convex quadratically constrained quadratic programming	CPLEX, Gurobi	⚡
Nonlinear programming	IPOPT	`nlpsol`

For Slim Malen, you need convex quadratically constrained quadratic programming (QCQP, a subset of second-order cone programs that is easier to work with), which is supported by CPLEX and Gurobi but not by CasADi qpsol or nlpsol.

The second slightly tricky aspect is that RTC-Tools provides the optimization problem as a general MX graph, i.e., not using any QP or QCQP structure even if it exists.

The way to go, then, is to:

Develop a new qcqpsol solver function in CasADi.
Develop CPLEX and Gurobi implementations for qcqpsol in CasADi.
Add code to RTC-Tools to re-cast an optimization problem in canonical {LP,QP,QCQP} form using Jacobians and Hessians.
Add code to check that the problem is indeed {LP,QP,QCQP}, but only evaluated in DEBUG mode.
Interface to qpsol, qcqpsol, or nlpsol in RTC-Tools, depending on the solver selected.

As an alternative, conversion to SOCP formulation may be considered, but I would recommend against this since this is less natural from a model differentiation point of view and probably also less efficient than going to (convex) QCQP; Gurobi's API is also focused on quadratic constraints.

In GitLab by @vreeken on Mar 23, 2018, 20:52

As far as item 1-2 are concerned, I have asked @jgillis to take a look at how SOCP problems should be handled in CasADi.

As far as item 4 is concerned, that is related to #1005. Evaluating naively would result in everything being a full NLP because of the quadratic equality constraints. We either have to (1) not make them in the first place, or (2) detect/ignore them when doing the LP/QP/QCQP check.

Item 4-5: I take it this means that you want the user to specify the solver (qpsol/nlpsol/etc) to be used? I think that is prettier/faster (and explicit > implicit), but just want to check.

In GitLab by @baayen on Mar 26, 2018, 09:20

With regards to SOCP, I'd advise caution. Reformulating a problem as an SOCP may require taking square roots of system matrices, which may become dense even as the original matrices are sparse. QCQP formulations do not suffer from this.

As to item 4-5: Yes, that'd be most elegant in my opinion.

In GitLab by @vreeken on Apr 16, 2018, 11:16

I am not too familiar with the various types of formulations, and how CasADi or Gurobi expect it to be formulated. I'll see if I can figure that out.

In GitLab by @vreeken on May 14, 2018, 12:36

mentioned in commit a4d39bd4da66799957525228581db3ed28d789c1

In GitLab by @vreeken on May 16, 2018, 16:49

mentioned in commit 078b19ea96d0da78ea62c0999320f0d07be72c8a

In GitLab by @vreeken on May 20, 2018, 24:46

mentioned in commit 2df96f96552d4dea8fa2239351fb86b039e0c1c0

In GitLab by @vreeken on May 26, 2018, 12:02

mentioned in commit bfe805f08be473a906dea90a2c07d589f6956c10

In GitLab by @vreeken on May 26, 2018, 12:03

mentioned in commit b2dc65d6130df00324ecfbf19bb74e11448bceb5

In GitLab by @vreeken on May 26, 2018, 12:11

closed via merge request !112

Deltares / rtc-tools

Support calling solver functions other than nlpsol #1007