<div dir="ltr"><div><div>Dear Ambros,<br><br></div>both parameters were indeed set at e-06; i lowered both as you suggested and so far the pricer hasn't got stuck on any instance.<br></div>Thanks for the suggestion!<br>
<div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,<br></div><div class="gmail_extra">Marco<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-05-21 14:48 GMT+02:00 Ambros Gleixner <span dir="ltr"><<a href="mailto:gleixner@zib.de" target="_blank">gleixner@zib.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Marco,<br>
<br>
I think changing numerics/epsilon is not the best idea. If I understand correctly, you are using SCIPisPositive() and friends to check the sign of your reduced costs.<br>
<br>
Instead you should use the primal and dual feasibility tolerance of the LP solver, which is returned by the methods SCIPlpfeastol() and SCIPdualfeastol(). (The corresponding parameters are numerics/lpfeastol and numerics/dualfeastol.) I believe you want to compare your reduced costs to SCIPdualfeastol().<br>
<br>
Changing numerics/epsilon has many other side effects, so I would really not recommend it.<br>
<br>
ambros<div class=""><br>
<br>
<br>
On 05/21/2014 10:41 AM, Marco Casula wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Dear Gerald,<br>
<br>
thanks for the input (also, thanks to Martin for ccing me his answer to<br>
Cristina).<br>
In the end, I think it was just a matter of solver tolerance: I am using<br>
SoPlex 1.7.2, and though I believed its tolerance to be e-12, by means<br>
of display/lpinfo I noticed a number of tolerance parameters set to<br>
e-06. Since I am not sure how to change the value of all of them, I<br>
lowered scip "numerics/epsilon" from the default e-09 to e-06, and so<br>
far the problem has not reappeared.<br>
<br>
Best,<br>
Marco<br>
<br>
<br>
2014-05-16 19:07 GMT+02:00 Gerald Gamrath <<a href="mailto:gamrath@zib.de" target="_blank">gamrath@zib.de</a><br></div>
<mailto:<a href="mailto:gamrath@zib.de" target="_blank">gamrath@zib.de</a>>>:<div><div class="h5"><br>
<br>
Dear Marco,<br>
<br>
sorry for the late reply. What you write sounds quite reasonable and<br>
you already tried most things that I would normally aks you for. So<br>
I don't see an obvious thing that might have gone wrong, and we<br>
probably need to dig a bit more into what happens.<br>
<br>
Therefore, please check the solution status of the LP when your<br>
pricer is called by calling SCIPgetLPSolstat(). Are you already in<br>
reduced cost pricing when the pricer keeps generating the same<br>
column? Also, please enable LP solver output by setting the<br>
parameter "display/lpinfo" to TRUE. When you checked the reduced<br>
cost of the previously generated variables, they were negative? What<br>
is the LP solution value of the "old" variable and what are its bounds?<br>
<br>
Another thing: did you mark all constraints to be modifiable?<br>
<br>
Best,<br>
Gerald<br>
<br>
Am 06.05.2014 18:59, schrieb Marco Casula:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Dear all,<br>
<br>
I am working on a branch and price algorithm for the VRP with time<br>
windows and stochastic travel times. While on many instances the<br>
algorithm terminates correctly, with a number of<br>
instances/parameters (delay distributions, penalties)<br>
combinations, the algorithm gets stuck as the pricer keeps<br>
regenerating the same column.<br>
<br>
I have found a similar case in the mailing list archives, and I<br>
tried every suggestion I found there, without success:<br>
the delay flag of the pricer is set to TRUE, as is the initial<br>
flag for the new variables (I had previously set this to FALSE,<br>
with the same result);<br>
the variables are added via SCIPaddPricedVar;<br>
I checked SCIPvarIsInLP for the variable added in the previous<br>
iteration of the pricer, and it is true;<br>
the reduced cost of the variable added in the previous iteration<br>
(via SCIPgetVarRedCost) coincides with the one i compute for the<br>
variable in the current iteration;<br>
I changed the upper bound on the variables from 1.0 to<br>
SCIPinfinity, with no effect.<br>
<br>
I was hoping for some more insight on the matter.<br>
Please find attached a logfile for a non working instance<br>
(terminated early), and the Pricer code.<br>
For completeness, here's a link to a full-working folder<br>
(including all source files)<br>
<a href="https://www.dropbox.com/sh/664n10xssiicd4o/G0xtWoLH2T" target="_blank">https://www.dropbox.com/sh/<u></u>664n10xssiicd4o/G0xtWoLH2T</a><br>
<br>
Thanks for any help<br>
Marco Casula<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Scip mailing list<br></div></div>
<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a> <mailto:<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a>><br>
<a href="http://listserv.zib.de/mailman/listinfo/scip" target="_blank">http://listserv.zib.de/<u></u>mailman/listinfo/scip</a><br>
</blockquote><div class="">
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Scip mailing list<br>
<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a><br>
<a href="http://listserv.zib.de/mailman/listinfo/scip" target="_blank">http://listserv.zib.de/<u></u>mailman/listinfo/scip</a><br>
<br>
</div></blockquote>
</blockquote></div><br></div></div></div></div></div>