0

I have asked this question before as "increasing solution time in a loop" here; https://www.ibm.com/developerworks/community/forums/html/topic?id=0ef4c99b-3bcc-4105-ac98-57867d5427da but the forum is currently not available.

Later, I realized that quadratic, second order cone programming constraints create a memory leak. Here is a summarized version of the code (source and the header can be found in the forum link above):

#include <header.h>
int main() {
 const int n = 10;
 const int ins = 30;
 // Parameters are read

 for (int i = 0; i < ins; i++) {
   IloEnv env;
   IloModel model(env);
   IloNumVarArray d(env, n + 1, 0, IloInfinity, ILOFLOAT);
   IloNumVarArray A(env, n + 1, -IloInfinity, IloInfinity, ILOFLOAT);
   IloNumVarArray C(env, n + 1, -IloInfinity, IloInfinity, ILOFLOAT);
   // Other variables are defined
   model.add((d[1] * d[1]) >= (A[1] * A[1]) + (C[1] * C[1])); // SOCP constraint 1
   model.add((d[2] * d[2]) >= (A[2] * A[2]) + (C[2] * C[2])); // SOCP constraint 2
   // Linear constraints are added according to the parameters of the instance
   // Solve method of IloCplex is called and outputs are collected
   env.end();
 }
}

When this code is executed, solution times are increasing with an increase in i and memory usage tool of Visual Studio shows that there is a memory leak with each loop. Memory leak disappears if SOCP constraints are commented out. Strangely, if only one of those SOCP constraints is added, either 1 or 2, memory does not leak. It leaks only if both of them (or more other SOCP constraints) are added at the same time.

Is there a problem of my way to add these quadratic constraints?

Thank you.

Edit: To reproduce file, you can use the following link: https://drive.google.com/open?id=1AAPaSUhGwdGZ15c3MEb0atRQsrAel-mJ. It includes the header, the source and the inputs.

Umur
  • 1
  • 2
  • Please provide more information as asked for in your crossposted question. – rkersh Apr 14 '20 at 02:37
  • I have edited the post and you can now find the link for the information (i.e., the header, source and the inputs) above. Thank you. – Umur Apr 15 '20 at 06:51

1 Answers1

0

This issue is partly resolved, by converting from CPLEX to GUROBI. Apparently, the inputs had some numeric issues, which is reported as a warning by GUROBI and which might be the reason of the increase in time for similar instances in CPLEX. After a couple of changes in optimization parameters, the model is successfully solved without an increase in time for the consecutive instances in GUROBI. But I want to mention that GUROBI still managed to provide suboptimal results even with numeric issues, and even in those, there was not any increase in time for the consecutive instances.

Additionally, I want to add that I have been suggested to change MKL_DISABLE_FAST_MM = 0, which is mentioned as a solution for some similar issues of mine in CPLEX. However, it did not solve my problem.

Umur
  • 1
  • 2