Originally posted by: SystemAdmin

[guwek said:]

I am doing branch-and-cut with CPLEX 9 using Concert and experience (for few problem instances instances) a strange segmentation fault in my cut callback.

Is this problem known? In the callback, I am just identifying violated cuts, say x1* + x2* > 3, and add them with, say,  add(x1 + x2 <= 3). I switched off presolve with cplex.setParam(IloCplex::PreInd, 0). Did I forget anything important?<br />
Thanks for any help.
Gunnar

PS. Here is what the debugger says:

(gdb) bt
#0  0x00000000005484bc in IloCallbackManager::getLinear ()
#1  0x00000000005488de in IloCallbackManager::getConstraint ()
#2  0x000000000054953b in IloCutCallbackManager::addCut ()
#3  0x000000000054977d in IloCplex::CutCallbackI::add ()
#4  0x0000000000460c6c in callbackI::main ()
#5  0x00000000005435c4 in IloCplexCallbackManager::call ()
#6  0x00000000006bb7af in CPXPcutcallback ()
#7  0x000000000070865f in CPXPfeasaftercuttable ()
#8  0x000000000067b71d in mipsetup ()
#9  0x00000000006799cd in mipopt ()
#10 0x00000000006790af in CPXPSmipopt ()
#11 0x000000000065cd50 in CPXmipopt ()
#12 0x000000000053602a in IloCplexI::solve ()
#13 0x0000000000891fab in IloAlgorithm::callSolve ()
#14 0x0000000000895e52 in IloAlgorithm::solve ()
#15 0x00000000004643b9 in IloCplex::solve ()
#16 0x000000000046331a in main ()
(gdb) 
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[EdKlotz said:]

> I am doing branch-and-cut with CPLEX 9 using Concert and experience (for
> few problem instances instances) a strange segmentation fault in my cut
> callback.
>
> Is this problem known?

I haven't seen this before.  Nonetheless, consider upgrading
to CPLEX 11, the latest version.

> In the callback, I am just identifying violated cuts, say x1* + x2* > 3, and
> add them with, say,  add(x1 + x2 <= 3). I switched off presolve with <br />> cplex.setParam(IloCplex::PreInd, 0).

You should not need to turn presolve off, but doing so does no harm.  Presumably you also encounter the segmentation fault with presolve enabled.


> Did I forget anything important?

That's hard to say without the code from your actual callback.  But, here are
some recommendations.

First of all, all standard debugging tactics apply.  Run Purify, Valgrind, Insure, or
some other memory debugger to try to shed light on the issue.  Turn on CPLEX's
datacheck parameter to see if it detects any problematic behavior before the invocation of the callback.  Look at the list of debugging suggestions on the support.ilog.com web site.

Specific to your program, try the following.

1)  Make sure you don't modify the original model within the callback.
2)  Make sure the cut added is correct.  Specifically, all variables in the cut
must be part of the model.
3)  Compare your cut callback with the ones in the CPLEX examples.  Look for differences that might explain the crash. 
4)  Compare your callback behavior on the models that cause the crash with
the models that don't.  That might shed some light on the problem.
5)  Try to systematically simplify your callback.  That may identify the problematic instruction in the callback.

If none of these suggestions help you identify the problem, please include the
actual callback code in your next post.

                                                                                      Ed


#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[guwek said:]

Ed,

thank you very much for your exhaustive and intelligent answer. Indeed, you hit the bull's eye with

> 2)  Make sure the cut added is correct.  Specifically, all variables in the cut
> must be part of the model.

I once made the same mistake (doing something with variables that are not part of the model). It can happen easily (at least for me, it seems) when devising a model and then moving a class of inequalities to a cut.

It seems that later versions of CPLEX now throw an exception, which would have helped a bit.

Anyway, thank you again.

Btw, I have two minor questions somebody might help me with.

* I am setting a time limit, but for some, large, instances, CPLEX seems to completely ignore it. Any ideas?

* After solve(), I do the following


    cout << "solution: " << cplex.getObjValue() << endl;<br />    cout << "lower bound: " << cplex.getBestObjValue() << endl;<br />

In the case of getStatus() == optimal I expect that solution and lower bound coincide. This is often not the case (note: I am using cutting planes, this might be the reason?)

Best wishes,
Gunnar


#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[EdKlotz said:]

> Btw, I have two minor questions somebody might help me with.
>
> * I am setting a time limit, but for some, large, instances, CPLEX seems to
> completely ignore it. Any ideas?

By default, CPLEX measures CPU time, not wall clock time.  So, if your large
instances require a lot of virtual memory usage, the CPU time may be significantly less than the wallclock time, and CPLEX may appear to ignore
your time limit.  If so, setting CPLEX's clocktype parameter (IloCplex::IntParam::ClockType in the C++ API) to 2 (wall clock time) should
resolve this.  If that doesn't do it, check to see if multiple processors is
somehow involved.  If the question persists, try posting some of the node log
output where CPLEX appears to ignore the time limit.

> After solve(), I do the following
>
>
> Code:
>    cout << "solution: " << cplex.getObjValue() << endl;<br />>    cout << "lower bound: " << cplex.getBestObjValue() << endl;<br />>
> In the case of getStatus() == optimal I expect that solution and lower bound > coincide. This is often not the case (note: I am using cutting planes, this
> might be the reason?)

By default, CPLEX uses a mipgap of .0001.  So, you could see slight differences,
but you shouldn't see big ones.  If you set the mipgap to a larger value, an
IloCplex::getStatus() call still return optimal; the solution is optimal within
the requested gap.  If you need to distinguish between truly integer optimal and
optimal within a positive mip gap (regardless of how small), use IloCplex::getCplexStatus instead.

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[guwek said:]

Ed,

Thanks for your quick answer.

>> Btw, I have two minor questions somebody might help me with.
>>
>> * I am setting a time limit, but for some, large, instances, CPLEX seems to
>> completely ignore it. Any ideas?

>By default, CPLEX measures CPU time, not wall clock time.  So, if your large
>instances require a lot of virtual memory usage, the CPU time may be significantly less than the wallclock time, and CPLEX may appear to >ignore
>your time limit.  If so, setting CPLEX's clocktype parameter (IloCplex::IntParam::ClockType in the C++ API) to 2 (wall clock time) should
>resolve this. 

Mmmh, no. I watched these processes with top and there is plenty of memory.

>If that doesn't do it, check to see if multiple processors is
>somehow involved.  If the question persists, try posting some of the node log
>output where CPLEX appears to ignore the time limit.

I am running processes on a dual-processor machine using only one of the two processors. Could that be the source of the problem?

node log... How do I generate this?

>> After solve(), I do the following
>>
>>
>> Code:
>>    cout << "solution: " << cplex.getObjValue() << endl;<br />>>    cout << "lower bound: " << cplex.getBestObjValue() << endl;<br />>>
>> In the case of getStatus() == optimal I expect that solution and lower bound coincide. This is often not the case (note: I am using cutting >> planes, this
>> might be the reason?)

> By default, CPLEX uses a mipgap of .0001.  So, you could see slight differences,
> but you shouldn't see big ones.  If you set the mipgap to a larger value, an
> IloCplex::getStatus() call still return optimal; the solution is optimal within
> the requested gap.  If you need to distinguish between truly integer optimal and
> optimal within a positive mip gap (regardless of how small), use IloCplex::getCplexStatus instead.

I do see big ones. I am sure the optimal solution is right (I get the same without cutting planes). The bound returnd by getBestObjVal seems not to be up to date. Could that be possible?

Thanks again for your effort,
Gunnar
#CPLEXOptimizers
#DecisionOptimization