Originally posted by: pankaichn

I use cplex 12.5 with C++ concert technology to solve a mixed-integer linear program problem. All the cplex are default. It stops with a solution that is shown optimal, but it doesn't reach the default relative mip gap tolerance, which is 0.01%. It seems weird to me. Is it possible for cplex to stop and show the solution is optimal, without reaching terminating optimality gap tolerance?

 

The output details are attached as follows.

 

 

 

You can see that cplex stop when only reaching a gap 0.31%.

#CPLEXOptimizers
#DecisionOptimization

You are misinterpreting the log here. CPLEX does not stop at gap 0.31%. This is only the last node log line it prints. By default, CPLEX does not print a log line for each node it processes. After printing the line with gap 0.31% it processes some more nodes but does not produce any log output for them. It manages to prove optimality before it would print the next node log line. That is why you do not see any additional node log lines. You can set the MIPInterval parameter to 1 to see a node log line for each node CPLEX processes. You could also query the number of nodes processed in your C++ application (IloCplex::getNnodes()) and you will see that this returns a value larger than 1246 (which is the last node for which CPLEX did print a log line).

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: pankaichn

Hi Daniel,

You are exactly right. Now I obtain the node log information for every node after setting MIPInterval to 1. Thanks a lot!

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: pankaichn

Problem still unsolved....I run another instance of my problem after setting MIPInterval parameter to 1. Although Cplex output the node log information for every node before it stops, but it still stops with a gap large than the default relative terminating gap tolerance 0.01%. Do I miss anything else?

 

//let's miss the lengthy output in the middle part...

 

 

You see, it output every node information before the 2455th node, but it stops at the node 2455 with gap 0.26%. I also query the number of nodes and nodes left using (IloCplex::getNnodes()), which are shown in the last four lines.

#CPLEXOptimizers
#DecisionOptimization

That indeed looks odd. What do cplex.getObjValue(), cplex.getBestObjValue() and cplex.getMIPRelativeGap() return after cplex.solve() returns?

Do you have any non-default parameter settings?

Could you export your model as a SAV file (cplex.exportModel("model.sav")) and share it here?

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: pankaichn

I've set the following parameters: setParam(IloCplex::TiLim, 3600); setParam(IloCplex::NodeFileInd, 3); setParam(IloCplex::MIPDisplay, 4); setParam(IloCplex::MIPInterval, 1). No others.

I apply cplex.getObjValue(), cplex.getBestObjValue() and cplex.getMIPRelativeGap() to get their results and the following are the results from a similar instance of my problem.

 

...

 

The return from cplex.getMIPRelativeGap() is significant, which is less than default 0.01%. But the node output information stops at node 3562 with gap 0.07%.

Attached is the model.sav file.

 

 

 

#CPLEXOptimizers
#DecisionOptimization

I think what you are observing is still correct/expected. CPLEX terminates with a gap of 8e-5 which is smaller than 1e-4, hence it is fine for CPLEX to terminate with status OptimalTol (optimal within the specified tolerances).

The gap 0.07% in the log is most likely due to thread synchronization: In deterministic multi-threading the different threads do not always synchronize solution information immediately. Instead they synchronize information periodically at so called "sync points". This means that between two sync points a thread may have slightly outdated information and may therefore print slightly outdated information to the log. The information a thread prints is never wrong but may not be as good as it could be. In your case I suppose that the value for the dual bound printed in the log is in fact a little larger than what it printed in the log (namely 7641.17). Right after CPLEX finds the incumbent at node 3562 the threads synchronize, learn about the better dual bound and recognize that they can stop immediately.

You could set the thread count to 1 (parameter IloCplex::Threads) and check if the log then makes more sense to you.

#CPLEXOptimizers
#DecisionOptimization