<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Dear Gregor,</div><div><br></div><div>Here, I list different configurations of presolving parameter in both scips and their effect:</div><div>1. OFF in scip & DEFAULT in scip2 => solution of scip2 is INFEASIBLE for scip & final solution of scip is NOT OPTIMAL (different than that of scip2)<br></div><div>2. OFF in scip & OFF in scip2 => solution of scip2 is FEASIBLE
for scip & final solution of scip is OPTIMAL (same as that of
scip2)<div>3. DEFAULT in scip & DEFAULT in scip2 => solution of scip2 is INFEASIBLE for scip & final solution of scip is OPTIMAL (same as that of
scip2)<br></div><div>4. DEFAULT in scip & OFF in scip2 => solution of scip2 is FEASIBLE
for scip & final solution of scip is OPTIMAL (same as that of
scip2).</div><div>So I suppose the bug appears when I turn on presolving for scip2. Please note that I cannot have default presolving settings in the original scip as it is going to be a master problem for column generation. Yet, these tests are done before I add the pricer and run column generation. Therefore, it is a VRP with some initial routes that make a complete solution and I want to examine this initial solution.<br></div><div><br></div><div>Under configuration 1, making "presolving/donotaggr" and
"presolving/donotmultaggr" TRUE in scip2 had no effect on the results I stated above. However, it changes the violated constraint. Before turning on these parameters in scip2, the violated constraint was in the form of `x1 + x2 + a*y <= 0` where variables x1 and x2 are continuous and y is binary: `[linear] <cap_con>: <x1>[C] (+180) +<x2>[C] (+0) -180<y>[B] (+0) <= 0`. The value of x1 in the solution of scip2 is 180 (same as here), but the value of y in that solution was 1 (scip takes it as 0 here).</div><div>When I set "presolving/donotaggr" and
"presolving/donotmultaggr" to TRUE, the solution of scip2 `violates original bounds of variable <z1> [0,0] solution value <1>` in scip. z1 is a binary variable which is 0 in the solution of scip2 and, later, in the solution of scip. <br></div><div>Without touching presolving/donotaggr" and
"presolving/donotmultaggr" in scip2, I tested this procedure on other instances to see which constraints are violated. The violation constraint differ but they are either in the linear form like `x1 + ... + xn + a*y <= 0` or some binary variable bounds. So I guess it is not deterministic.<br></div><div><br></div><div>Going back to configuration 1, both scip and scip2 have identical OrigProblem lp files (as expected). When I write TransProblems, scip2 has the following statistics just after calling SCIPpresolve(scip2):</div><div>\ Variables : 252 (151 binary, 2 integer, 0 implicit integer, 99 continuous)<br>\ Constraints : 158<br>\ Obj. scale : 0.1<br>\ Obj. offset : 4050</div><div>And it has the following statistics after calling SCIPsolve(scip2):</div><div>\ Variables : 252 (151 binary, 2 integer, 0 implicit integer, 99 continuous)<br>\ Constraints : 139<br>\ Obj. scale : 0.1<br>\ Obj. offset : 4050</div><div>whereas for scip, I get the following statistics after calling SCIPsolve(scip2):</div><div>\ Variables : 609 (464 binary, 6 integer, 0 implicit integer, 139 continuous)<br>\ Constraints : 504<br>\ Obj. scale : 0.1<br>\ Obj. offset : 0<br></div><div>The OrigProblem has the following statistics (same for both):</div><div>\ Variables : 609 (464 binary, 6 integer, 0 implicit integer, 139 continuous)<br>\ Constraints : 514<br>\ Obj. scale : 1<br>\ Obj. offset : 0<br></div><div><br></div><div>When I look at the `cap_con` in the TransProblem of scip2, it is transformed into `+1 t_x1 +1 t_x2 <= +180` (i.e. y is set to 1) in both of its transformed problems (i.e. after SCIPpresolve(scip2) and after SCIPsolve(scip2)). However, there is no `cap_con` in TransProblem of scip! I think this is where the problem occurs, but I cannot see how.</div><div><br></div><div>Thank you for your consideration, I would really appreciate your help.<br></div><div><br></div><div>Saleh<br></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 8:57 PM Gregor Hendel <<a href="mailto:hendel@zib.de" target="_blank">hendel@zib.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Dear Saleh,<br>
<br>
this is indeed a bit strange. <br>
<br>
There is probably a numerical problem. For starters, you can use
presolving, but avoid multiaggregations by<br>
setting the two boolean parameters "presolving/donotaggr" and
"presolving/donotmultaggr" to TRUE in your scip2. They are often the
reason for numerical troubles in the original space.<br>
<br>
Unfortunately, you have optimized out some of the relevant
information to help you, such as the type and violation of the
constraint that is violated.<br>
<br>
Two questions: <br>
1. I assume that if you do *not* disable presolving in the original
SCIP, the bug is not triggered?<br>
2. If the problem is a simple MIP problem, have you tried to write
out the transformed problems of both SCIPs? You could write them in
lp-format, which is very readable for small instances, and check
what has happened to the violated constraint after presolving in the
problem copy.<br>
<br>
To do so, use <br>
<br>
SCIP_CALL( SCIPpresolve(scip2) );<br>
<a class="m_-5093916288650450367m_-1929924134169489837code" href="https://scip.zib.de/doc-6.0.0/html/group__GlobalProblemMethods.php#gada41a57fc5a464ad565763d24e588d3a" target="_blank">SCIP_CALL(
SCIPwriteTransProblem</a>(scip2, "presolvedprob.lp", "lp", false)
)<br>
<br>
Maybe one of my guesses gets you started already,<br>
Gregor<br>
<br>
<br>
<div class="m_-5093916288650450367m_-1929924134169489837moz-cite-prefix">Am 02.11.18 um 17:58 schrieb M. Far.:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Hi</div>
<div>I am working on a simple MILP problem in
SCIP's c++ interface using CPLEX as the LP
solver.</div>
I have to disable presolving in my original
problem 'scip'. So I have:<br>
</div>
<div dir="ltr">SCIP_CALL( SCIPsetPresolving(scip,
SCIP_PARAMSETTING_OFF, true) );</div>
<div>after creating scip. Then, I need to solve a
copy of the problem by creating a second problem
'scip2':</div>
<div>SCIP* scip2;</div>
<div>SCIP_CALL( SCIPcreate(&scip2) );<br>
SCIP_CALL( SCIPcopyOrig(scip, scip2, nullptr,
nullptr, "copyProb", false, false, nullptr) );<br>
SCIP_CALL( SCIPsetIntParam(scip2,
"display/verblevel", 2) );</div>
<div><br>
</div>
<div>And I can turn on presolving procedure in
this problem. So I have:<br>
</div>
<div>`SCIP_CALL( SCIPsetPresolving(scip2,
SCIP_PARAMSETTING_DEFAULT, true) );`<br>
</div>
<div dir="ltr">
<div><br>
</div>
<div>Next, I want to add the solution of scip2
as an initial feasible solution to the
original problem. Hence:</div>
<div>```</div>
<div>SCIP_CALL( SCIPsolve(scip2) );<br>
auto sol2 = SCIPgetBestSol(scip2);<br>
SCIP_Bool stored;<br>
SCIP_CALL( SCIPaddSolFree(scip, &sol2,
&stored) );</div>
<div>```<br>
</div>
<div>However, when I solve the original scip by
calling `SCIPsolve(scip)`, I get the following
message in the output:</div>
<div>```<br>
</div>
<div>violation: right hand side is violated by
<a_number><br>
all 1 solutions given by solution candidate
storage are infeasible</div>
<div>```<br>
</div>
<div>Next, it ignores the solution, solves the
problem, and finds an "optimal solution" which
is inferior to sol2 (hence, not optimal
indeed).</div>
<div><br>
</div>
<div>I understand that something may be wrong
with the transformation. But I do not know how
to fix this.<br>
</div>
<div>(OS: Linux 4.15, SCIP ver.: 6.0.0, CPLEX
ver.: 12.8.0, gcc ver.: 7.3.0)<br>
</div>
<div><br>
</div>
<div>Bests,<br>
<div dir="ltr" class="m_-5093916288650450367m_-1929924134169489837m_-1887873641005988722gmail-m_-4202621538027297685m_8836857469212455087m_-4500597847004404067gmail_signature">
<div dir="ltr"><br>
</div>
</div>
</div>
<div>Saleh<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_-5093916288650450367m_-1929924134169489837mimeAttachmentHeader"></fieldset>
<pre class="m_-5093916288650450367m_-1929924134169489837moz-quote-pre">_______________________________________________
Scip mailing list
<a class="m_-5093916288650450367m_-1929924134169489837moz-txt-link-abbreviated" href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a>
<a class="m_-5093916288650450367m_-1929924134169489837moz-txt-link-freetext" href="https://listserv.zib.de/mailman/listinfo/scip" target="_blank">https://listserv.zib.de/mailman/listinfo/scip</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Scip mailing list<br>
<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a><br>
<a href="https://listserv.zib.de/mailman/listinfo/scip" rel="noreferrer" target="_blank">https://listserv.zib.de/mailman/listinfo/scip</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-5093916288650450367gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">M Saleh F<br></div></div>