<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Gerald,</p>
<p>First of all, thank you for taking the time for the detailed
answer.</p>
<p>For the moment we let scip handle all branching decisions and do
not generate valid inequalities, therefore we have not yet
implemented the constraint handler.<br>
</p>
<p>We modified our pricer so as not to forbid the generation of
columns that may have already been generated during previous
iterations. That did not solve our issue, which means that it had
nothing to do with scip's internal pricer (otherwise we would have
simply regenerated the right columns and converged to the right
solution).</p>
<p>We are still investigating our issue and the vbc visualisation
tool helped identifying that some nodes where declared infeasible
when we did not think that they were. This remains to be
confirmed, but the issue may be in the model itself.</p>
<p>Again, thank you very much for the support,</p>
<p>Best regards,</p>
<p>Sandra<br>
</p>
<br>
<br>
<div class="moz-cite-prefix">Le 03/07/2018 à 14:05, Gerald Gamrath a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:6b3ebf4b-0f2c-b55e-8cc5-dd765d4ce4ba@zib.de">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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>
</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">http://homepages.laas.fr/sungueve</a>
-----------------------------------------------
<a class="moz-txt-link-abbreviated" href="mailto:ngueveu@laas.fr">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">sandra.ngueveu@enseeiht.fr</a>
Département GEA
INP-ENSEEIHT
2 rue Charles Camichel
31071 Toulouse - France</pre>
</body>
</html>