Originally posted by: mrmag

Yes, the cut callback is invoked before cuts from the usercutpool are separated. You could just return from the cut callback without doing anything the first time it is invoked for a node.

If you get duplicate cuts then also make sure that they are not only violated by some small epsilon (which may be due to numerics).

Originally posted by: mrmag

Originally posted by: TobiasAchterberg

There is a difference between the root node and nodes deeper in the tree. And for non-root nodes there is also a difference between deterministic and opportunistic parallel mode, and between different CPLEX versions.

At the root node, it basically (in CPLEX 12.5.1) like this:

1. Solve LP relaxation.
2. If not enough progress since last iteration, goto 11.
3. Call heuristic callback.
4. Call CPLEX internal heuristics.
5. Apply probing.
6. Call cut callback (wherefrom = CPX_CALLBACK_MIP_CUT_LOOP). If user signaled to terminate loop, goto 11.
7. Separate CPLEX internal cuts and the user cut pool.
8. Call pumpreduce to try to pivot to a "more integral" vertex on the optimal face of the LP polyhedron.
9. Filter cuts (also filter user cuts if indicated by the user's cut purging flag).
10. Goto 1.
11. Call the cut callback (wherefrom = CPX_CALLBACK_MIP_CUT_LAST).
12. If any cuts have been found, filter cuts and goto 1.

With CPLEX 12.5.1, the cuts at non-root nodes are separated as follows:

1. Solve LP relaxation.
2. If not enough progress since last iteration, goto 7.
3. Call cut callback (wherefrom = CPX_CALLBACK_MIP_CUT_LOOP). If user signaled to terminate loop, goto 7.
4. Only during the first cut loop iteration: If cut callback did not find any cuts, separate CPLEX internal cuts and the user cut pool. Here, it can happen that the user cut pool is not looked at if some other CPLEX internal cut separator found cuts.
5. Filter cuts.
6. Goto 1.
7. Call the cut callback (wherefrom = CPX_CALLBACK_MIP_CUT_LAST).
8. If any cuts have been found, filter cuts and goto 1.

Hope this helps...

Originally posted by: mrmag

Originally posted by: TobiasAchterberg

Yes. In the C API you would check the wherefrom flag and only apply your separator if it is CPX_CALLBACK_MIP_CUT_LAST. I don't know right now how this is done in Concert, but I am pretty sure that there is a method of the IloCutCallback class that provides the information whether you are inside the cut loop or whether this is the last call to the cut callback.

Originally posted by: mrmag

Originally posted by: TobiasAchterberg

Yes, as I said it can happen that the user cut pool is not separated, if CPLEX' internal cuts found already some cut. You just cannot assume that all cuts in the user cut pool are satisfied by the LP solution that your cut callback sees, even if you check isAfterCutLoop().

Is this a big issue for you? Note that CPLEX will not put two identical cuts into the LP relaxation.

Originally posted by: mrmag

Actually, my separation problem is very time consuming. Therefore I wanted to allocate basic cuts in the user cut pool (without separation) and then generate only extended user cuts. But the problem is that my separation generates in ILOUSERCUTCALLBACK basic cuts which I already added. This is a double work as you see. It was more convenient to have a user callback after CPLEX internal cuts and user cut pool are satisfied. 

Originally posted by: TobiasAchterberg

I see. Then maybe the easiest and best solution is just that you separate all your cuts with the cut callback. Instead of adding some of them to the user cut pool in advance, just add those to a table that you manage yourself. This should be really simple: just store a list of those cuts in your own data structures, and then always check these cuts for violation first in your cut callback. Don't worry about the performance or memory overhead, because this is nothing else that CPLEX does internally with the cut pool. So, the CPLEX internal user cut pool is not better than what you would get with managing your user cuts yourself.

Originally posted by: mrmag

Originally posted by: TobiasAchterberg

As I said, there is nothing smart in the CPLEX internals here. In each iteration, we just add all user cuts to the intermediate cut storage that are violated by the current LP solution (of course, that are violated by at least some minimum amount). Then, the cuts in the intermediate cut storage are filtered as usual and the surviving cuts are added to the LP relaxation.

The cut filtering is slightly different for cuts coming from the callback and the user cut pool, but this should not matter too much.

Originally posted by: mrmag

I see. Tobias, thank you for the answer.