Decision Optimization

Decision Optimization

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


#Analytics
#DecisionOptimization
#DecisionOptimization
 View Only
Expand all | Collapse all

IloCplex getStatus() vs. IloCplex::ContinuousCallbackI isFeasible(), inconsistent?

  • 1.  IloCplex getStatus() vs. IloCplex::ContinuousCallbackI isFeasible(), inconsistent?

    Posted 08/27/17 08:04 AM

    Originally posted by: davidfk


    Hi all,

    I'm using CPLEX 12.7.0 with concert C++. I'm solving an LP and use IloCplex::ContinuousCallbackI to check if a feasible solution has been found and if a time limit has been exceeded. That is, I want to stop the solver after a given time limit, but not before a feasible solution has been found. The main body of the callback looks similar to:

    if (isFeasible() && elapsed_time >= time_limit){
        abort();
    }
    

    Once the solver stops (either due to the abort() call or because of optimality), I call the getCplexStatus() and getStatus() method of my IloCplex instance. If the LP was solved before reaching the time limit, I get (as expected): getCplexStatus() = "Optimal" and getStatus() = "Optimal"

    If the solver was stopped by the abort() call in the callback, it always holds that getCplexStatus() = AbortUser. The IloCplex solve() method, however, sometimes returns IloTrue together with IloCplex getStatus() = "Feasible" and sometimes solve() returns IloFalse together with getStatus() = "Unknown".

    I would expect solve() to return IloTrue and getStatus() to be "Feasible" if the isFeasible() method of the IloCplex::ContinuousCallbackI class returned true.

     

    What could be a reason for IloCplex::ContinuousCallbackI isFeasible() and IloCplex getStatus() not being consistent in this case?

    And how can I make sure the LP solver is stopped once a feasible solution is found that can be extracted, e.g. using IloCplex getValues() or similar?

     

    Some more observations: I use concurrent optimization. I can see in the console output that CPLEX finds better primal solutions (using primal simplex). If I call the getObjValue() method of the IloCplex::ContinuousCallbackI class just before abort() (in line 2 of code above), it returns a reasonable objective function value. In case the IloCplex solve() method returns IloFalse afterwards, the value obtained by calling IloCplex getObjValue() is of no value (it seems arbitrary to me).

    Is there any way I can extract variable values within the callback, when isFeasible() returns true? What exactly is happening after the abort() call so that an apparently feasible solution is lost?


    #CPLEXOptimizers
    #DecisionOptimization


  • 2.  Re: IloCplex getStatus() vs. IloCplex::ContinuousCallbackI isFeasible(), inconsistent?

    Posted 08/28/17 12:31 PM

    Originally posted by: EdKlotz


    > What exactly is happening after the abort() call so that an apparently feasible solution is lost?

    At the point your callback calls abort(), unless CPLEX just refactorized the basis matrix, the internal representation consists of the basis factorization along with updates to the updates to the factorization that can accumulate some round-off error.   When you stop the optimization, CPLEX will refactorize the basis.   If the model is ill conditioned, it is possible that after computing a fresh factorization CPLEX discovers the computed solution is no longer feasible.

     

    I suggest you add a call to IloCplex.getQuality to get the final basis condition number and accuracy of the computed solution.   That should help you assess whether bad numerics or ill conditioning is involved here.

     

    > Some more observations: I use concurrent optimization.

    If you use concurrent optimization, you need to make sure your callback is thread-safe.   I'd recommend simplifying the situation by running the program with primal or dual simplex only.  Let's see if you can still reproduce the unexpected results.   

     


    #CPLEXOptimizers
    #DecisionOptimization