Originally posted by: SystemAdmin

Hi to everyone,

I am developing a Branch and Cut algorithm using CPLEX 12.1 Callable Library. For the LP relaxation algorithm, I'm setting the following parameters

CPX_PARAM_SUBALG 4
CPX_PARAM_BARCROSSALG -1

to evaluate the computational times of the barrier algorithm since relaxations are usually hard to solve.

I look at the log file and I notice that at each round of each node of the Branch and Cut tree, the barrier algorithm is runned three times providing exactly the same objective value every time, performing exactly the same iterations.

I would like to know if this is the usual behaviour for the barrier algorithm or if it is possible to set some parameters to avoid this situation, since every LP relaxation is very time consuming. In case it helps, I can provide with the information in the log file.

Thanks in advance for any thoughts or commentaries in this regard,

Paula.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Yes, please post a log. Please use only one thread, and set the MIPDISPLAY parameter to 5.

Tobias
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hi Tobias,

Thank you very much for your quick answer.
I'm attaching the log file.
We do 15 rounds of cutting planes at root node and 3 rounds in the remainig nodes. There is also a heuristic callback activated. CPLEX cuts and heuristics are disabled. If you need any further information please let us know.

Thanks again for your help,

Paula.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Indeed, this looks like superfluous work that we might be able to avoid.
I will investigate this.

Tobias
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I found the issue in the code. In certain situations we update the bound vectors for the LP relaxation (in case we found tighter bounds) and clear the solution status of the LP relaxation. We do this even if the new bounds are identical to the old ones. Of course, for simplex this is not an issue, because the old warm start basis will still be optimal, but barrier gets screwed as it cannot warm start...

So, this is a performance bug in our code, and we need to fix it with the next release.
Unfortunately, there is no work-around for this and for now you have to live with the situation.

Tobias
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Dear Tobias,

Thank you very much again for your quick answer. The log file we posted corresponds to an easy instance of our problem. For bigger instances, where LP relaxations are much harder to solve, this extra work is quite representative and that called our attention.

Thanks again we look forward for any insight you may get for this issue,

Paula
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I have found a potential work-around: downgrade CPLEX to version 12.1.

It looks like the biggest part of this performance issue was introduced during the 12.2 release cycle. Downgrading to CPLEX 12.1 should get you some relief. CPLEX will still solve the initial LP relaxation twice, but from thereon it should only solve each LP relaxation once.

Hope this helps...

Tobias
#CPLEXOptimizers
#DecisionOptimization