Originally posted by: IntVar

I'm not sure why OPL is not solving this MIQCP model when it finds the only solution to a relaxed model that is actually clearly feasible for the more restrictive that it decides is infeasible.

 

 

#DecisionOptimization
#OPLusingCPLEXOptimizer

There are two problems here:

1. You have hit on a bug in CPLEX presolve for quadratic constraints. The only way to work around this bug is to set CPX_PARAM_REDUCE to 0 or 2.
2. You constraint quadraticExpr1 >= 0 is not convex. Your model only solves by luck because CPLEX manages to fix all variables in presolve. With the above setting it will no longer be able to do that and will error out with "CPLEX Error  5002: 'q1' is not convex."

#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: IntVar

Please help here in my thinking and correct what is wrong:

 

I believe only point 1 is the issue since CPLEX allows non-convex MIQCPs if the variables in the quadratic term are binary variables

(see http://www.ibm.com/support/knowledgecenter/SSSA5P_12.6.3/ilog.odms.cplex.help/CPLEX/UsrMan/topics/discr_optim/mip_quadratic/03_introMIQCP.html :

Conditions on the constraints

Each constraint in the MIQCP model must satisfy at least one of the following conditions:

·         The constraints that contain a quadratic term can be represented as second order cone programs (SOCP). The topics Characteristics of a quadratically constrained program and Convexity are also relevant here.

·         The quadratic term in a constraint involves only multiplication of binary variables.)

 

In the discussions at the end of https://www.ibm.com/developerworks/community/forums/html/topic?id=78f71712-e52d-427f-b328-e152a5a22b2b&ps=25it was confirmed that this is accomplished by CPLEX using an appropriate transformation.

So the point here is that the transformation into a convex QCP occurs in the presolve, so when the presolve gets turned off, then CPLEX correctly identifies the untransformed model as not convex.

But the only reason that presolve was turned off was because there was a bug in the way it does this transformation (or something else in the process).

 

As for point 2, the model isn't solved by luck ​(unless the luck is with regards to avoiding the bug in the presolve!). 

Below is another version, that shows two things:

1. With a fourth choice, CPLEX can solve it and finds the solution that it is supposed to be feasible in the previous example (that is the first 3 variables set to 1)
2. When the first 3 variables are set to 1, then it can't find a solution

So, I would conclude that the bug occurs sometimes because CPLEX is forced a solution and doesn't have any choices.  The previous example shows that this depends on constraints that may or may not have impact logically to the model, and so it somewhat arbitrary to the user.

 

There was a post by drhare last year that exhibited the same behavior (https://www.ibm.com/developerworks/community/forums/html/topic?id=6e055bb3-dd61-4068-8ca8-1e8d6613f8d6&ps=25)

The problem there was that a warm start was not being accepted by as a solution in a MIQCP even though it determined by previously solution.   I think it is the same presolve bug that caused this problem there as well, of not having a choice, in a MIQCP model.  The models were actually unlucky because of the presolve!

The presolve bug was a recognized issue in CPLEX 12.6.1 and is still in CPLEX 12.6.3.  Do you know the plan as to when it is to be fixed?

 

Other version:

 

floatquadraticCoeffs[1..4] = [ 0.224446143, 0.273033212, 0.360849435, 0.5 ];

floatlinearCoeffs[1..4] =  [0.185048615, 0.247846998,  0.241304981, 0.5 ];

floatfactor1 = 1.087;

floatfactor2 = 1.1364;

     

dvar booleanx[1..4];

 

dexpr floatquadraticExpr = pow(sum(i in 1..4) quadraticCoeffs[i] * x[i], 2);

dexpr floatlinearExpr = sum(i in 1..4) linearCoeffs[i] * x[i];

dexpr floatquadraticExpr1 = quadraticExpr - factor1*linearExpr;

dexpr floatquadraticExpr2 = quadraticExpr - factor2*linearExpr;

 

subject to

{

       sum(i in 1..4) x[i] == 3;

       quadraticExpr1 >= 0.0;

       quadraticExpr2 <= 0.0;

       

       // by adding a 4th variable

       // now gives the solution with

       // quadraticExpr2 equal to -0.029433

       // (same one as the second experiment of the previous model

       //  and the same as one set below)

 

       // but commenting out the next 3 constraints,

       // presolve determine it is infeasible

       // x[1] == 1;

       // x[2] == 1;

                 // x[3] == 1;

}

 

 

#DecisionOptimization
#OPLusingCPLEXOptimizer

Sorry, my formulation was a bit sloppy. With "by luck" I meant this: CPLEX can handle only convex constraints. One exception is the case in which all variables in the quadratic constraint are binary. In this case in presolve CPLEX can transform the quadratic constraint into something it can handle. So with presolve enabled you were "lucky" that CPLEX managed to get rid of the problematic constraint. With presolve disabled this transformation is no longer done and CPLEX (correctly) rejects the constraint. I think you understood this all correctly.

The bug reported by drhare last year was something completely different (although it may look similar at first glance).

#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: IntVar

This has now been fixed in 12.7.0 !!

#DecisionOptimization
#OPLusingCPLEXOptimizer