[Dip] Implicit Polyhedra and GAP

Matthew Galati magh at lehigh.edu
Tue Sep 7 12:50:41 EDT 2010


>    4) This is related to 3). If indeed, redCostX is the vector of all
>>    variables then I suppose I could easily do what I wrote you about
>>    earlier this  summer, namely solve the blocks in parallel. That is I
>>    could take redCostX and in my own code, in parallel solve a problem
>>    for each block and then when each solveRelaxed() is called in turn,
>>    give it the solution from my parallel solve. Does this make sense?
>>
>>
>> Not yet. Two issues there. (1) the logic by default is to loop over all
>> blocks and call the solveRelaxed for each value of whichBlock. So, if you
>> solved all in parallel, you'd get too many. You, could, of course, just
>> solve the "first one" for all and then skip the rest. But, that is an ugly
>> hack. (2) The argument convexDual is the dual associated with the convexity
>> constraint for `whichBlock`. To do what you want, you really need all the
>> duals for the convexity constraint. Again, you could "get this" by grabbing
>> the full dual vector from the master LP and parsing it yourself - but that
>> gets tricky when you add in cut and branch constraints to the master -- the
>> accounting is tricky.
>>
>
>
>
> But for each block, convexDual affects the value of the reduced cost, but
> it has no effect on which column I choose. The convexDual does not affect
> the subproblem solution, only the solution value. Therefore, in the first
> call to solveRelaxed (whichBlock = 1) I can use redCostX for all the
> variables and simultaneously find the best column for each subproblem. Then
> when the other subproblems are called (whichBlock >1) I simply take the
> column from the first call (do not solve again) and return it. The
> convexDual did not affect that solution. Hope I  am making sense here.
>


Yep. You are correct, convexDual does not effect the pricing. It only
effects the "check" for negative RC (if you choose to do that as a user -
you don't need to actually) and, the constructor for a DecompVar. The latter
could be redesigned so the user doesn't need to provide it and the internal
adjusts it for you. Either one, a change (or addition) in the API would make
this cleaner. I will think about this and get back to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/dip/attachments/20100907/b2d0e75a/attachment.html 


More information about the Dip mailing list