Decision Optimization

Decision Optimization

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

 View Only
Expand all | Collapse all

Concurrent Optimizer using Barrier Algorithm with no crossover produces infeasible while other algorithms do not?

  • 1.  Concurrent Optimizer using Barrier Algorithm with no crossover produces infeasible while other algorithms do not?

    Posted Thu February 18, 2016 02:44 PM

    Originally posted by: E_Orrico


    Hello,

    I was using CPLEX to solve an LP using a barrier algorithm ( cplex.setParam(IloCplex.IntParam.RootAlg, 4) ) set to not do barrier crossover (  cplex.setParam(IloCplex.IntParam.BarCrossAlg, -1)  )  with the concurrent optimizer. This was producing an infeasible answer while using barrier crossover or other algorithms (primal, etc) would produce feasible. Next, I set the root algorithm to the "automatic" setting, while still turning barrier crossover off and got this warning:

    Warning: concurrent optimization will not use barrier because
    crossover was disabled.

     

    What does this mean? Can I be sure my program is feasible? I have attached the lp file here.

     

    Thanks in advance for your help.


    #CPLEXOptimizers
    #DecisionOptimization


  • 2.  Re: Concurrent Optimizer using Barrier Algorithm with no crossover produces infeasible while other algorithms do not?

    Posted Tue February 23, 2016 11:50 AM

    NOTE: Due to some technical difficulties, I'm posting this reply from @EdKlotz 76679752-a695-4301-a8a6-a46603aab7bb​:

    I had a look at your model.   Regarding the message:

    > Warning: concurrent optimization will not use barrier because
    > crossover was disabled.

    That has occurred because you have disable the crossover in the code.   The default concurrent optimization will run barrier
    and dual (and possible primal) simplex all at the same time.  Since the simplex methods provide basic solutions, it makes sense for the barrier method to provide a basic solution as well.   So, concurrent optimization requires the crossover to be enabled.   If you disable it, you will get the above warning.

    Regarding your next question:

    > Can I be sure my program is feasible?

    Examining the solution quality can help you assess this.  Running your model with primal simplex method indicates
    the solution computed is very accurate:

    There are no reduced-cost infeasibilities.
    Max. unscaled (scaled) bound infeas.        = 6.66134e-016 (8.32667e-017)
    Max. unscaled (scaled) Ax-b resid.          = 1.90425e-012 (9.81437e-014)
    Max. unscaled (scaled) c-B'pi resid.        = 2.27374e-013 (2.27374e-013)
    Max. unscaled (scaled) |x|                  = 6 (1.5)
    Max. unscaled (scaled) |slack|              = 10000 (10000)
    Max. unscaled (scaled) |pi|                 = 968.792 (2923.52)
    Max. unscaled (scaled) |red-cost|           = 0 (0)
    Condition number of scaled basis            = 5.9e+004

    The residuals associated with the solutions are all very small, and a condition number of 5.9e+4 indicates your
    model is quite well conditioned.   This all looks good.  However, if I ran barrier with crossover or dual simplex,
    the results are not as good.  Note the large unscaled bound infeasibility:

    Iteration:   131   Dual objective     =            -5.724242

    Maximum unscaled bound infeasibility = 1.38258.

    Dual simplex - Optimal:  Objective = -5.7242419840e+000
    Solution time =    0.03 sec.  Iterations = 153 (0)
    Deterministic time = 17.66 ticks  (569.78 ticks/sec)

    CPLEX> d sol qu
    There are no reduced-cost infeasibilities.
    Max. unscaled (scaled) bound infeas.        = 1.38258 (8.35092e-007)
    Max. unscaled (scaled) Ax-b resid.          = 3.31168e-012 (5.12923e-014)
    Max. unscaled (scaled) c-B'pi resid.        = 2.84217e-014 (2.84217e-014)
    Max. unscaled (scaled) |x|                  = 6 (1.5)
    Max. unscaled (scaled) |slack|              = 10000 (10000)
    Max. unscaled (scaled) |pi|                 = 127.264 (573.782)
    Max. unscaled (scaled) |red-cost|           = 0 (0)
    Condition number of scaled basis            = 3.1e+004


    This merits some additional investigation.   The solution quality indicates that the bound violations were just barely within the feasibility tolerance on the scaled model, but unscaling the model resulted in a much bigger infeasibility.   This suggests a scaling issue regarding the variable bounds or the matrix columns.   Sure enough, if we examine the problem statistics for your model, we see large values for the variable bounds:

    CPLEX> d pr st
    Problem name         : infeasibleexample.lp
    Objective sense      : Maximize
    Variables            :      82  [Box: 82]
    Objective nonzeros   :       2
    Linear constraints   :    5640  [Less: 4000,  Greater: 1600,  Equal: 40]
      Nonzeros           :   22145
      RHS nonzeros       :    4016

    Variables            : Min LB: -1.000000e+008   Max UB: 1.000000e+008  
    Objective nonzeros   : Min   : 0.3500000        Max   : 0.6500000      
    Linear constraints   :
      Nonzeros           : Min   : 1.000000         Max   : 5400825.       
      RHS nonzeros       : Min   : 1.000000         Max   : 10000.00 
          

    In general, you don't want to use such large bounds.   Either declare the variables as free variables, or use smaller variable bounds.  In this case declaring the variables as free variables works better.  In that case, the barrier method runs without crossover and finds an optimal solution of good quality, as do both the primal and dual simplex methods.

    Since you apparently are using the C++ API, to do this, you need to use -IloInfinity and +IloInfinity for the bounds in the IloNumVar constructors you use to create your model variables.

    Ed

     


    #CPLEXOptimizers
    #DecisionOptimization