Originally posted by: UserCplex

Hello,

I am getting multiple errors with the above CPX function. I am using C callable library with CPLEX 12.7.1

 

The scenario is as follows:

I have a mycallback function declared thus:

 

int CPXPUBLIC mycallback(CPXCENVptr env, void *cbdata, int wherefrom, void *cbhandle);

 

mycallback is an MIP callback function, setup thus:

 

status = CPXsetmipcallbackfunc(env, mycallback, (void *)this);

 

Before a call to CPXmipopt, I write down the MIP using CPXwriteprob thus:

 

CPXwriteprob(env, lp, "problemIP.sav","SAV");

 

However, I get the following errors within the callback function (errors are presented after the code snippet)

 

 

//other code

}

 

Depending on certain conditions somewhere else in my program, the errors described below occur when the files that are written right before CPXmipopt are ProblemIP_notok.sav and ProblemIP_notok.lp (both files attached). When the written files are ProblemIP_ok.sav and ProblemIP_ok.lp (both files attached), few of the errors described below occur.

 

(E1)wherefrom is 107 in case of ProblemIP_notok.sav while it is 101 in case of ProblemIP_ok.sav

(E2)CPXgetcallbackinfo(env, cbdata, wherefrom, CPX_CALLBACK_INFO_NODE_SEQNUM, (void *)&ndseq); returns an error status 1003 with both ProblemIP_notok.sav and ProblemIP_ok.sav.

(E3)status = CPXgetcallbacknodelp(env,cbdata,wherefrom,&nodelp_p); returns an error status of 3003 with ProblemIP_notok.sav

 

In both cases (case 1 where ProblemIP_notok.sav is produced, and case 2 where ProblemIP_ok.sav is produced), the CPLEX parameters that are set are the same -- default cplex parameters. Inspite of this, in both cases, the console window displaying MIP solution progress seems to show different progress.

In the case where there are errors (case 1), CPLEX seems to be doing some aggregation/preprocessing (see screenshot notok_start.jpg attached). When there is only one error, E2, (case 2), the screenshot looks different (see screenshot ok_start.jpg)

 

Thanks in advance for your time.

 

ETA: Additional information.

 

The MIP is created by first creating an LP, solving a sequence of LPs, doing a few other things and then converting the problem to an MIP using CPXchgctype on the continuous variables to make them integer. This is followed by CPXchgprobtype(env,lp,CPXPROB_MILP);

 

In the case where all three errors occur (Case 1), only one LP is solved using CPXbaropt after setting CPXsetintparam(env, CPX_PARAM_BARCROSSALG, 2); After this the problem is changed to MIP.

In the case where only error E2 occurs (Case 2), only the first LP is solved using CPXbaropt. The remaining sequence of LPs are solved using CPXdualopt. After this, the problem is changed to MIP.

 

If in case 1, I force usage of CPXdualopt in place of CPXbaropt, errors E1 and E3 go away. But error E2 continues to occur

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: EdKlotz

Why don't you try simplifying the by taking one of the admipex*.c examples, modifying it to use your callback, and trying to reproduce a single 1003 error status?   Two things can happen.   Either you can reproduce the 1003 error, in which case you've got something simpler to work with (and something more easily digestible to everyone else on the forum).   Or you cannot reproduce the error, in which case you can start comparing this simple example to your code to help determine the source of the problem.
 

#CPLEXOptimizers
#DecisionOptimization

I am not quite sure I got all of your details correctly, but I am wondering whether the problems go away if you just jump out of the callback (without doing anything) when it is invoked with wherefrom==107 (CPX_CALLBACK_MIP_PROBE)? Some information may just not be available in that context since it is very early in the optimization process.

#CPLEXOptimizers
#DecisionOptimization