[Dip] generateCuts Question

[Matthew Galati]

Kipp - the example you sent finds the optimal solution after a few passes of
pricing and therefore never calls the cut generator. By default, the PC
solver, in the root node starts with pricing, and does not stop until it
prices out (or finds optimal, or within gap limits).

If it prices out and has not yet found optimal, then it will proceed to
cuts.

This is parameter driven.


You'll see in the log file (LogDebugLevel = 3),
PRICE_AND_CUT  LimitRoundCutIters       2147483647
PRICE_AND_CUT  LimitRoundPriceIters     2147483647

This is the number of Price/Cut iterations to take before switching off
(i.e., MAXINT).

To force it to cut before pricing out, change this parameter in the parm
file. For example, if you change to :

[DECOMP]
LimitRoundPriceIters = 1
LimitRoundCutIters   = 1

It will then go into your generateCuts after one pricing iteration.







On Tue, Oct 5, 2010 at 7:24 PM, Kipp Martin <kmartin at chicagobooth.edu>wrote:

> Hi:
>
> The class DecompApp has a virtual function
>
>
> virtual int generateCuts(const double  * x,
>      DecompCutList & newCuts);
>
>
> I have implemented this function in a class that derives from DecompApp.
>  When solving an integer program that has an integer LP relaxation
> value, generateCuts() does not get called. This seems like a potential
> problem for routing problems where I might want  generateCuts() to
> generate subtour elimination constraints. It is possible to have an
> integer solution and a subtour so I want generateCuts called even with
> an integer solution.
>
> Indeed, in the sample code, TSP_DecompApp.cpp I see the implementation
> of generateCuts() calls in turn generateCutsSubtour(). But will
> generateCuts() get called if there is an integer solution? It seems like
> it should, yet I have an example where generateCuts() is not being
> called when the LP is integer.
>
> Thanks
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/dip/attachments/20101007/2e0ab680/attachment.html