<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) This is related to 3). If indeed, redCostX is the vector of all<br>
variables then I suppose I could easily do what I wrote you about<br>
earlier this summer, namely solve the blocks in parallel. That is I<br>
could take redCostX and in my own code, in parallel solve a problem<br>
for each block and then when each solveRelaxed() is called in turn,<br>
give it the solution from my parallel solve. Does this make sense?<br>
<br>
<br>
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.<br>
</blockquote>
<br>
<br>
<br></div>
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.<br>
</blockquote><div><font color="#888888"><br><br style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 0);">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.</span> <font color="#888888"><span style="color: rgb(0, 0, 0);">I will think about this and get back to you.</span></font><br>
</font><br></div></div>