<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear Sandra,<br>
<br>
I thought about this again and I am quite sure where this large
number originates from. As you might know, all variables that you
create during pricing are valid globally. However, the corresponding
columns are only added to the current LP. When jumping through the
tree, the LP is restored to the state it had when this node (or the
parent node) was processed, so that a warmstart can be performed
from the basis of the parent node. The variables that you priced in
at other parts of the tree, but whose columns are then not part of
the LP anymore, are then potentially added to the LP by the variable
pricer of SCIP. The more you proceed in the tree search, the more
open nodes you have at which columns found at other nodes may be
added to the LP, so this number increases faster.<br>
<br>
There is no option to disable this. You might want to consider
setting the delay flag of your pricer to FALSE, if you did not do so
already, so that you pricer is only called if the variable pricer
did not add a column in this pricing round.<br>
<br>
Concerning your issue: I agree that the optimal solution should be
the same as long as you always add at least one improving column if
there exists one. But adding more or less columns changes the LP and
might lead to different LP solutions, thus a changed
branch-and-bound tree, and different solutions being found. In rare
cases, this might trigger a bug in SCIP that you do not come across
otherwise, or perhaps also your pricer stops because reduced costs
changed slightly and are now zero or not zero anymore (within
tolerances).<br>
<br>
What you could do (but I would only recommend this for debugging): I
assume you have a constraint handler that takes care of your
branching decisions and fixes variables locally to 0 that were
created at other nodes and to not comply with the branching
decision. A very drastic step would be to just fix all variables to
0 that have been created at other nodes. This would as a consequence
disable the variable pricer and only your pricer could add
variables.<br>
<br>
Best,<br>
Gerald<br>
<br>
<div class="moz-cite-prefix">On 28.06.2018 09:01, Sandra Ulrich
Ngueveu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:784116f7-4f80-c9ff-c57c-1c021b14d658@laas.fr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Hello Gerald,</p>
<p>Thank you very much for your reply.</p>
<p>The model is small (302 variables).</p>
<p>Setting parameter age limit to -1 does not seem to deactivate
scip internal pricing (442 variables from our pricing versus
66334 from scip). <br>
</p>
<p>Also, let me specify that at the beginning of each pricing
phase<em> </em><em style="font-style: normal; color: rgb(106,
106, 106); font-family: arial,sans-serif; font-variant-caps:
normal; letter-spacing: normal; text-align: left; text-indent:
0px; text-transform: none; white-space: normal; word-spacing:
0px; -moz-text-size-adjust: auto; -webkit-text-stroke-width:
0px;">PRICERREDCOST, </em>we displayed the number of
variables previously added by our pricer and the result of
SCIPgetNPricevarsFound. During several iterations, the two
numbers were the same. But at some point the second number
becomes higher than the first, and the difference between the
two numbers increases until the end of the branch-and-price.<br>
</p>
<p>The statistics displayed at the end (with scipprintstatistics)
showed that scip's pricer is very fast (0.03s), so we not longer
expect to gain any speed-up there. <br>
</p>
<p>But we would still like to deactivate it if possible, to help
us investigating the following issue : Let's consider two
disjoint sets of columns S1 and S2, and their union Sall (= S1 U
S2). We are trying to understand why in our branch-and-price,
adding Sall leads to a worse final solution than adding S1
example. Therefore we are carefully rechecking our code and we
would like to deactivate scip's pricer if possible.</p>
<p>Best regards,</p>
<p>Sandra<br>
</p>
<br>
<div class="moz-cite-prefix">Le 25/06/2018 à 19:19, Gerald Gamrath
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:e9054c09-0e83-0763-a649-1c6f19d31bd2@zib.de">Dear
Sandra, <br>
<br>
I don't think that SCIPgetNPricevarsFound returns what you are
interested in. As far as I can see, this is the total number of
variables that were added to the to the pricestore. This may be
variables "priced" by SCIP, but also the variables you priced,
as well as all variables in your original formulation, that go
through the pricestore once to enter the LP. Perhaps your
original formulation is quite large? <br>
<br>
Setting the age limit to -1 should normally do the trick. There
are other things like "lp/cleanupcols(root)", but those are
disabled by default. <br>
<br>
When you look at the statistics after solving ("disp stat" in
the interactive shell or SCIPprintStatistics()), you should see
how many variables are really added by your pricer and by the
internal SCIP pricing ("problem variables"). Is there a nonzero
number for the latter? <br>
<br>
Best, <br>
Gerald <br>
<br>
On 25.06.2018 18:28, Sandra Ulrich Ngueveu wrote: <br>
<blockquote type="cite">Hello, <br>
<br>
We are doing a Branch-and-Price with SCIP. Using function
"SCIPgetNPricevarsFound", we realized that a very higher
number of variables were "priced" by scip, compared to the
number of columns that we explicitely added (127253 instead of
475). <br>
<br>
We would like to deactivate such internal pricing (which
according to some forum is related to column aging) just to
verify if the code would be faster for our specific problem.
We tried setting parameter lp/colagelimit to -1, but the
number of additional pricedvars declared by scip remained
unchanged. <br>
<br>
Could you please tell us if there is another parameter we
could activate or deactivate to achieve the desired behaviour
? <br>
<br>
Best regards, <br>
<br>
Sandra U. Ngueveu <br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Maître de Conférences / Associate Professor
-----------------------------------------------
<a class="moz-txt-link-freetext" href="http://homepages.laas.fr/sungueve" moz-do-not-send="true">http://homepages.laas.fr/sungueve</a>
-----------------------------------------------
<a class="moz-txt-link-abbreviated" href="mailto:ngueveu@laas.fr" moz-do-not-send="true">ngueveu@laas.fr</a>
Equipe ROC
LAAS-CNRS
7 avenue du Colonel Roche
31031 Toulouse Cedex 4 - France
-----------------------------------------------
<a class="moz-txt-link-abbreviated" href="mailto:sandra.ngueveu@enseeiht.fr" moz-do-not-send="true">sandra.ngueveu@enseeiht.fr</a>
Département GEA
INP-ENSEEIHT
2 rue Charles Camichel
31071 Toulouse - France</pre>
</blockquote>
<br>
</body>
</html>