Decision Optimization

Decision Optimization

Delivers prescriptive analytics capabilities and decision intelligence to improve decision-making.


#Analytics
#DecisionOptimization
#DecisionOptimization
 View Only

Determining which CPLEX algorithm was used to solve an optimization problem

  • 1.  Determining which CPLEX algorithm was used to solve an optimization problem

    Posted 07/29/10 02:28 PM

    Originally posted by: SystemAdmin


    In our C++ application we would like to report which CPLEX algorithm that was used to solve an optimization problem. Any advice on that would be appreciated. Some of our thoughts and results can be found below.

    As we use Concert C++, we can utilize cplex.getAlgorithm() to get the algorithm. There are couple of problems with this approach. First, getAlgorithm() only returns Primal, Dual, Barrier or MIP, which means that no details are returned for MIP algorithms, while it would be useful for us to report something like "MIP, root Dual, node Barrier". Second, if the problem was solved by Barrier algorithm with the crossover, getAlgorithm() returns Primal or Dual depending if primal or dual crossover algorithm was used. Third, there is no way to determine if the concurrent algorithm was run as getAlgorithm() only reports the algorithm that solved the problem.

    For now, we use the following pseudo-code to report the solution algorithm:

    
    usedAlg = cplex.getAlgorithm();   
    
    if ((LP or QP) and (usedAlg==
    "Primal" or usedAlg==
    "Dual")) then       
    
    if (cplex.getNbarrierIterations()>0 and cplex.getNiterations()==cplex.getNbarrierIterations()) then  usedAlg = 
    "Barrier, " usedAlg 
    " crossover";
    


    For continuous problems (LP, QP, QCP) the code reports the algorithm used (plus crossover algorithm if crossover was used). For concurrent algorithm, it reports the algorithm that solved the problem. Checking both conditions cplex.getNbarrierIterations()>0 and cplex.getNiterations()==cplex.getNbarrierIterations() may be an overkill. The second condition was added to accommodate the cases if for concurrent optimization Primal or Dual algorithm solves the problem at the same time when Barrier was doing the crossover, as it is not clear if cplex.getNbarrierIterations() is set after barrier has finished or after crossover has finished. For MILP, MIQP and MIQCP the algorithm reported is MIP.

    For more detailed reporting, e.g., "MIP, root Dual, node Barrier", the information can be constructed from the problem type (MILP, MIQP or MIQCP) and parameter settings (RootAlg, NodeAlg, etc.), but this approach requires testing all the settings with every new version of CPLEX. Another possibility may be to use callbacks for getting extra information about MIP algorithm or for determining if the algorithm was concurrent, but that looks like an overkill to us.

    Another reason why we do not want to check the problem type and parameter settings for reporting the algorithm is that those may be inconsistent and we have discovered a number of bugs related to those. Just to name a couple of bugs (in case it is useful for CPLEX developers):

    For QP problems, concurrent algorithm only works if called as
    
    cplex.setParam(static_cast<IloCplex::IntParam>( CPX_PARAM_QPMETHOD ), IloCplex::Concurrent)
    
    When called as
    
    cplex.setParam(IloCplex::RootAlg, IloCplex::Concurrent)
    
    auto (barrier) algorithm is used.

    For MIQCP problems, setting NodeAlg to Barrier results in "CPLEX Error 1031: Not available for quadratically constrained programs", while setting it to AutoAlg or Concurrent (which actually reverts to barrier) allows solving the problem.
    #CPLEXOptimizers
    #DecisionOptimization