Originally posted by: 8699oriel

Hi,

I have a MIQCP that I will add TSP cuts to in a cut callback.  I successfully do this with a MIP I solve, but am having issues here.  The .sav file looks fine before the call to mipopt but the very first cut callback node .sav has many of the constraints all messed up, many missing, and a bunch of 'junk' constraints that look like " >= 0", and has some bizarre columns with names like "QL0" and "CV1".

1. I think the most likely reason is that I am butchering the memory somewhere - I'm working on using Dr. Memory to rule that out or fix it.

2. The other option is that I'm misunderstanding MIQCP parameters and callbacks and I'm hoping you can help me rule this out.  I'm setting the MIQCP strategy to 1 which, to my understanding, says that each node in a standard Branch/Cut tree solves a QCP.  Mip search strategy is "CPX_MIPSEARCH_TRADITIONAL".  Linear Reduction Switch is set to 0.  I'm also turning off all presolves .

So my question is - is there any "normal" reason (due to wrong parameter settings) that my callback subproblems have all these messed up constraints?  Or, does this match what you'd expect from corrupt memory.  I'm going to separately email the two .sav files to illustrate.

Thank you!

-William

Yes, there is a good reason the model in the callback looks different: even with presolve disabled CPLEX has to perform a minimal transformation to get the problem into a form it can handle. You may want to try setting CPX_PARAM_MIPCBREDLP to 0, then all functions in the callback work on the original rather than the presolved model.

Originally posted by: 8699oriel

Hi Daniel,

Thank you,

What exactly is the model you are dumping from the callback? How did you obtain this model?

Originally posted by: 8699oriel

I build the model via Callable Library methods.  It's a variant of the TSP with some SOCP constraints.

A similar TSP variant I have successfully solved for a few years using callbacks - separating and adding TSP cuts at the cut callback on the original model (no presolve or reductions or anything).  

So I just wanted to verify that if all the parameters above are set, that the root node callback subproblem should appear the same as right before the call to mipopt.  Then I'll have confirmed that the problem is somewhere in my code.

I'd be fine sending you the sav files before/after but didn't want to attach them here.

Thanks,

-William

Sorry, it seems my question was not precise enough. Do you get the model via CPXgetcallbacknodelp(), CPXgetcallbacklp() or CPXgetcallbackinfo(CPX_CALLBACK_INFO_USER_PROBLEM)?

MIQCP is different than MIP. Even if you disable all presolve reductions, CPLEX will still perform some transformations that are required to get a problem that CPLEX can handle internally. Depending on which model you query, these transformations may be visible in the model (and look odd).

Originally posted by: 8699oriel

Daniel,

Sorry I didn't answer your question properly last time.  I get the model via CPXXgetcallbacknodelp() and then, using the local (callback) CPXCENVptr and CPXLPptr objects, write the sav file to compare.  

You are right that I'm probably expecting things to look too much the same and I'm beginning to mentally set there.  I think a couple of my concerns are still valid though - but maybe I'm not on the right track?:

1. My old MIP-only problem (TSP constraints but strictly linear in obj func and constraints), using 12.2, goes straight to a cut callback before reaching the incumbent callback.  Now, both the strictly linear MIP and with my new MIQCP model, the incumbent callback is reached first.  Is this a new path through CPLEX that I simply must adapt to?  

2.  I get that CPLEX has its internal constraint names at callbacks but here's what I'm seeing:

   -before call to mipopt: "Constraint1: A1*x <= b1" and "Constraint2: A2x <= b2"

  -at first cut callback, the node lp has "Constraint1: A2*x <= b2" and "Constraint2: A1x <= b1"

  i.e. it's using my constraint names but pointing them at different constraints.  This just seems wrong rather than odd.  

You can see this in the .sav files I sent.

BTW - my old code was on a 32-bit machine and used the CPX interface.  Now that I have a 64-bit machine, I updated to CPXX interface and changed to CPXDIM and CPXINT where appropriate to avoid compiler warnings/errors.  One of my tests in the next few days is to create a copy of the code that only uses the CPX interface (not CPXX) in case somehow I've screwed things up there.

Thank you for your patience and help.

-William

I still think that everything you see is somehow expected (and everything should be independent of whether you use CPX or CPXX).

1. That an incumbent callback is called first is not very surprising. We have improved on heuristics in the past, so it looks like one of the heuristics now finds a solution before CPLEX even attempts to separate the first cut. So you have to adapt to that. Note that this may have happened even in 12.2. You were just unlucky that the heuristics implemented in this version did not find a feasible solution.
2. I don't see such 2 constraints in the files you sent. Could please tell me the exact names of two such constraints? In general I can see how CPLEX could to presolve reductions that make it look like it mixed up the constraint or variable names.

Let me repeat that looking at the nodelp in your case is not the correct thing to do. You were just lucky that it worked without problem in the MIP case. You should set CPX_PARAM_MIPCBREDLP to 0 and look at the problem returned by CPXgetcallbackinfo(CPX_CALLBACK_INFO_USER_PROBLEM). If I understand correctly then your cuts rely on a model structure that is only present in the original model and may have been destroyed by presolve? In that case, setting CPX_PARAM_MIPCBREDLP to 0 you can get the current relaxation in terms of the original model, separate and submit the constraint in terms of the original model, and CPLEX will automatically translate the constraint to the presolved model. So I am unclear why you want to fiddle with the nodelp at all.