The candidate context means CPLEX
thinks it has a feasible solution ... and is asking you to verify feasibility. So if you abort, CPLEX cannot be sure that solution is actually feasible.
That said, it would be appropriate for CPLEX to return "feasible" if you abort (within the candidate context) after an incumbent solution has been accepted. Failure to do so would be a bug in my mind. For that matter, I am hard-pressed to think of a situation in which returning "optimal" after an abort would not be a bug, since presumably the gap would be above the gap tolerance setting at the point that abort was called (else CPLEX would already have ended). The one exception I can see there is that, with multiple threads, it might be possible for one thread to shrink the gap to the point of convergence while another thread is getting aborted.
------------------------------
Paul Rubin
Professor Emeritus
Michigan State University
------------------------------
Original Message:
Sent: Sun August 01, 2021 03:11 AM
From: Viktor Bindewald
Subject: Cplex 20.1: terminate solving process in candidate context within a generic callback
Dear community,
I would like to terminate the solving process from a generic callback based on some criteron. I'm using the candidate context because I'm adding cuts as lazy contraints. If I'm using context.abort() then Cplex.status is set to "unknown". Is this behavior correct? Being in a candidate context means that an integer solution was found so status should be at least "feasible" (I've made sure that abort() is not called for the first candidate found)? Am I missing a key point here?
Using context.abort() from other contexts seem to lead "feasible" or "optimal" cplex.status.
Thanks in advance
------------------------------
Viktor
------------------------------
#DecisionOptimization