<div dir="ltr"><div>Hello Gerald, Lukas, <br><br></div><div>it is impossible for branching to cause this since I've relaxed the problem and it still happens. Still, Lukas, I have implemented my own specialized branching rules, and have accounted for their duals on the pricing problem. Thank you for your input anyway. <br><br></div><div>About the problem variable pricer and PRICER_DELAY, yes, I have set it to true, following the Binpacking example on SCIP's website. However, now that you mentioned the variable pricer, I must ask: is it always included by default? I have verified that the value I'm getting for SCIPgetNPricers and SCIPGetNActivePricers during solving is 1. Since this one is surely my own pricer, what happened to the problem variable pricer? Does it not count for this function, or could I have failed to include it somehow? Reading the FAQ entry "I only implemented one pricer, why is there a second one, called variable pricer?" leads me to believer I should expect a value of 2 for
SCIPgetNPricer... Note: I have called SCIPincludeDefaultPlugins. <br><br></div><div>Thanks again, <br></div><div>André<br>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 26 de set. de 2022 às 03:16, Gerald Gamrath <<a href="mailto:gamrath@zib.de">gamrath@zib.de</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi André,</p>
<p>SCIPvarIsInLp returns whether the variable is in the LP at the
current node. As you mentioned, a variable may not be in the LP
because it is removable and was aged out. Another reason why a
variable may not be in the LP is if it was priced at another node
of the branch-and-bound tree. Then, it was added to the LP there,
but when SCIP jumps to another node in the tree, only the
variables that were in the LP at its parent node will be in the LP
initially.</p>
<p>Did you set PRICER_DELAY to TRUE for your pricer? The problem
variable pricer adds existing variables with negative reduced
costs to the LP and will be called before your pricer. If
PRICER_DELAY is TRUE, your pricer won't be called in a pricing
round where already variables have been added, i.e., if the
variable pricer found existing variables with negative reduced
costs, those will be added, the LP will be reoptimized, and a new
pricing round will be started. Thus, when your pricer is called,
there should not be any columns with negative reduced costs.</p>
<p>Best,</p>
<p>Gerald</p>
<div>On 9/26/22 08:00, André Mazal Krauss
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
Hello <span>SCIP</span> team, <br>
<br>
I'm currently working on a VRP-related application, using <span>SCIP</span>. I'm using a Set Partitioning
formulation with Branch & Price, and my formulation is a
minimization problem.
In fact, I've already asked a question about a month ago, and
this is related to the same application. <br>
<br>
</div>
<div>At that time, I was having serious problems with duplicate
routes. After following your suggestions and working more by
myself on the problem, I've managed to <i>almost</i>
eliminate the pricing of repeated routes. In fact, while
previously it was a certain occurrence, now I'm finding about
100 repeated routes across my 1500 test instances. Anyway, I
wanted to understand what was going on and try to eliminate
them entirely. <br>
<br>
</div>
<div>Upon investigating this, I've noticed a common trait
between all these repeated routes being found. 1. The problem
persists even when I relax the formulation and use continuous
variables; 2. The negative RC my pricing has computed matches
exactly with the one given by SCIPgetVarRedCost; 3. the
already existing variable is <i>always</i> active ( ie.
SCIPvarIsActive is true), but is <i>never</i> in the LP (ie.
SCIPvarIsInLp is false); 4. upon inspecting the other
variables in the problem, I've noticed that there are
typically several active variables with negative RCs, but not
in the LP; it's just that sometimes I happened to price one of
them again. <br>
<br>
</div>
<div>I found this quite strange. How does this make sense? If
the variables have negative RCs, shouldn't SCIP put them in
the LP and use them? I'm not sure I understand exactly what
SCIPvarIsInLp means. How does it relate to the variable being
removable and/or deletable? I've tried changing my variable
creation to make them <i>not </i>removable and <i>not</i>
deletable, but this had no impact whatsoever. If I price a
variable and it isn't in the LP anymore, should it be added
again? When and why would SCIP decide to remove a variable RC
from the LP? <br>
<br>
</div>
<div>I was thinking for some time that this could maybe be
explained by my primal problem having multiple optimal
solutions, which could, in turn, mean the dual has multiple
optimal solutions, and my pricing algorithm would be somehow
affected by this. But then again, I may be overthinking this
and the problem may be simpler, or maybe not a problem at all.
It really depends on what SCIPvarIsInLp actually means.<br>
<br>
</div>
<div>Note: I have read the FAQ entry "Why are not all variables
in the LP?", but it does not seem to address my case since I
have tested without branching and the problem persists even
when I set removable to false in all variables. <br>
</div>
<div><br>
</div>
<div>Thanks again for your help, <br>
</div>
<div>André<br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Scip mailing list
<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a>
<a href="https://listserv.zib.de/mailman/listinfo/scip" target="_blank">https://listserv.zib.de/mailman/listinfo/scip</a>
</pre>
</blockquote>
</div>
</blockquote></div>