Originally posted by: rbl25

Hi,

I have a relatively small/medium MIP problem that is taking too long to be solved.

A Concorde function is called inside the usercuts (only on the root node) and the lazzyconstraints to separate some subtour elimination constraints.

I'm using the default parameters of cplex, except for the linear relaxation, which I imposed the barrier algorithm (the default parameter here takes much more time, around 300 seconds, against 5 seconds when the barrier is imposed).

CPXPARAM_LPMethod                                4
CPXPARAM_QPMethod                                4
CPXPARAM_Threads                                 1
CPXPARAM_MIP_Tolerances_MIPGap                   0.001
CPXPARAM_MIP_Strategy_StartAlgorithm             4
CPXPARAM_MIP_Strategy_CallbackReducedLP          0

The problem has 23175 rows, 20083 columns, 137436 nonzeros, and 373 binaries variables.

The problem has been solved for 34435 seconds and the gap found until this time is around 48%.

The output for this instance follows attached.

I would like to know if anyone has any suggestion about any cplex parameter that can be changed to improve the resolution of the problem.

Thank you.

The node throughput is really slow, do you have an idea where the time is spent? Are you sure it is not spent in your callback?

You have explicitly set the number of threads to 1, is that a requirement or can you use more threads?

What version of CPLEX do you use? If you are using 12.8 then instead of a lazy constraint/user cut callback you could use the new generic callback. That does not disable MIP features like dynamic search (which are disabled by user cut and/or lazy constraint callback).

It takes CPLEX relatively long to find a first feasible solution. Do you have any means to come up with a first feasible yourself, no matter how bad that is? If so you could add this as MIP start and see if things go better. As soon as CPLEX has a feasible solution it can run improvement heuristics on this which may improve performance.

Originally posted by: rbl25

Thanks for your answer.

I don't think cplex is spending most of the time in the callbacks. Mainly because the subtour elimination constraints are being separated when a fractional solution is found only on the root node and just after cplex finishes its own cuts and heuristics (isAfterCutLoop() == true).  As it took so long to find an incumbent solution, I don't think either that the problem is into the lazzy constraints.
To verify if the problem was on my callbacks, I tried to solve the problem without separating the subtour elimination constraints (or without implementing callbacks). And the performance was not good as well.

Anyway, the time spent each time cplex enters in a callback is being printed now. The problem is being run again, so I can be sure or not about this.

When I'm using callbacks can I use multithread without any problem?

Actually, I'm using CPLEX 12.7. The CPLEX 12.8 is being downloaded now. Do you know where can I find an example of an implementation in c++ of the new generic callbacks?

Even though it takes too long to find a feasible solution when I don't have the callbacks, do you still thinking the problem can be in their utilization?

Thank you.

Originally posted by: rbl25

It follows attached the output of cplex when the linear relaxation of the problem is solved.

We can see a message as:

***NOTE: Found 218 dense columns.

(The problem is solved two times because after the first time, SECs are separated and the problem needs to be resolved).

Does it give us any tip about the difficult to solve the problem?

Thank you!

Originally posted by: rbl25

I'm solving the version of this problem without separating SECs, which means that in this version there are no callbacks.

Now, CPLEX 12.8 is being used.
It took around 2500 seconds to find an incumbent solution.

The first GAP is around 66%.

After finding the first integer solution, the GAP improves very slowly.

Until now, the model has been solving for 14000 seconds, and the GAP is around 62%.
The output of CPLEX follows attached.

While you could try setting CPX_PARAM_MIPEMPHASIS to 1 or 4, it seems the main issue with your model is the node throughput.

So we/you have to figure out, why your LPs solve so slowly. I think you are already discussing that with Ed Klotz on another thread?