<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Jan and list,<br>
<br>
yes, it is possible that the global bounds are shrunk further during
the solving process. Every time a solution is found, the global
problem changes because only the remaining part of your BIP search
space remains to be searched. This can have the side effect that
even the incumbent solution is not feasible for the global
(transformed) problem anymore after it was found.<br>
<br>
<br>
I would suggest you verify the feasibility of a solution against the
original problem (the one before the problem transformation) using
SCIPcheckSolOrig() instead of SCIPcheckSol(). That method uses
original, unpresolved bounds.<br>
<br>
By the way, in order to completely disable presolving, you should
use <br>
<br>
SCIPsetPresolving(scip, SCIP_PARAMEMPHASIS_OFF,
true_or_false_for_quiet_output).<br>
<br>
Yet, this will not affect bound reductions during search caused by
the behavior described above.<br>
<br>
Happy feasibilty checking,<br>
Gregor<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 16.06.2016 um 16:39 schrieb Jan
Berling:<br>
</div>
<blockquote
cite="mid:CAPeMmq1K36gZNwKXEs+DsvWfjh6VQU8yy+YUR0SfDkb_utu_FA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Jakob,<br>
<br>
</div>
The problem is a pure IP, pure BIP. <br>
<br>
The infeasibility is not due to the constraints but due to
the boundaries, as only the check for bounds results in
infeasibility: <br>
</div>
<br>
SCIP_ERR(SCIPcheckSol(scip, mysol, 1, 1, 0, 0,
&isSolFeasible), "Error checking if sol is feasible");<br>
<br>
</div>
<div>The boundaries of the variables are lb = 0.0 and ub = 0.0,
which is seen by<br>
<br>
SCIPvarGetLbGlobal(var)<br>
SCIPvarGetUbGlobal(var)<br>
<br>
</div>
<div>Is it possible that the boundaries are changed or that the
variables are fixed in the solution process? Presolving is
disabled by<br>
<br>
SCIPsetBoolParam(scip, "lp/presolving", FALSE);<br>
<br>
</div>
<div>I tried to manually change the bounds but this didn't have
any effect.<br>
<br>
var-><a moz-do-not-send="true" href="http://glbdom.lb">glbdom.lb</a>
= 0.0<br>
var->glbdom.ub = 1.0<br>
</div>
<div><br>
</div>
<div>Is it possible to "unfix" the variable or make it possible
to change the value without violating bounds?<br>
<br>
</div>
<div>Cheers,<br>
</div>
<div>Jan<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-06-16 9:15 GMT+02:00 Jakob Witzig
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:witzig@zib.de" target="_blank">witzig@zib.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jan,<br>
<br>
you already mentioned numerical troubles, I can imagine two
reasons for the infeasibility:<br>
<br>
Do you have pure IP or a MIP?<br>
<br>
1) If you have a MIP your continuous variables need not fit
with the new solution value (even if you just 'polished' the
value). In that case you may should try to fix all your
integer values and resolve the resulting LP again.<br>
<br>
2) If you have a pure IP changing one solution value can
lead to infeasibility due tu numerical troubles, e.g, 1e+07
* x + y == 1 with x = 1e-07 and y = 0, both binary and
feasibility tolerance 1e-06. Changing x to 0 will violate
your constraint. Sure, this corner-case will be detected by
each MIP solver but it should illustrate the issue. In that
case, you have to do some clever relaxing of variables and
you need to resolve the reduced problem. Just an idea for
relaxing variables: If you change the solution value a
variable x you could relax all variables in the
1-neighbourhood, i.e., variables sharing constraints with x.<br>
<br>
I hope this will help.<br>
<br>
Cheers,<br>
Jakob
<div>
<div class="h5"><br>
<br>
<br>
Am 15.06.2016 um 18:52 schrieb Jan Berling:<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 mailing list,<br>
<br>
when we manually change a variable of a feasible
solution which was<br>
found by the scip solver, the solution becomes
infeasible, even though<br>
it was feasible before and we know that it has to be
feasible<br>
afterwards, from problem-knowledge.<br>
<br>
SCIP_ERR(SCIPsetSolVal(scip, mysol, var, 0),
"error setting<br>
solution value");<br>
SCIP_ERR(SCIPcheckSol(scip, mysol, 1, 1, 1, 1,
&isSolFeasible),<br>
"Error checking sol");<br>
<br>
Is it possible to change solution variables that way
and check for<br>
feasibility?<br>
<br>
We tried to copy the solution, transformed the
variables, checked that<br>
the variables we change are active, tried
SCIPtrySol(),...<br>
<br>
Our reasoning behind this approach:<br>
<br>
Due to numerical inaccuracies, scip sometimes finds
inaccurate solutions<br>
for our binary integer problem. We would like to round
non-integer<br>
variables manually after the solution is found. But
simple rounding to<br>
the nearest value (e.g. 0.99999999 to 1.0) leads to
infeasible solutions<br>
in some cases. From the knowledge about our problem,
we know which<br>
variables we can set to guarantee feasible but poor
solutions. To<br>
improve our solutions, we would like to try to round
variables first,<br>
check if the resulting solution is feasible and if not
choose the poor<br>
variables as a last option.<br>
<br>
Kind regards,<br>
Jan<br>
<br>
<br>
</div>
</div>
_______________________________________________<br>
Scip mailing list<br>
<a moz-do-not-send="true" href="mailto:Scip@zib.de"
target="_blank">Scip@zib.de</a><br>
<a moz-do-not-send="true"
href="http://listserv.zib.de/mailman/listinfo/scip"
rel="noreferrer" target="_blank">http://listserv.zib.de/mailman/listinfo/scip</a><br>
<br>
</blockquote>
<br>
<br>
-- <br>
Jakob Witzig<br>
<br>
Zuse Institute Berlin (ZIB)<br>
<br>
Division Mathematical Optimization and Scientific
Information<br>
Research Group Mathematical Optimization Methods<br>
<br>
Takustrasse 7<br>
14195 Berlin<br>
<br>
Tel. : <a moz-do-not-send="true"
href="tel:%2B49%20%280%2930%2084185-416"
value="+493084185416" target="_blank">+49 (0)30 84185-416</a><br>
Fax : <a moz-do-not-send="true"
href="tel:%2B49%20%280%2930%2084185-269"
value="+493084185269" target="_blank">+49 (0)30 84185-269</a><br>
email: <a moz-do-not-send="true"
href="mailto:witzig@zib.de" target="_blank">witzig@zib.de</a><br>
_______________________________________________<br>
Scip mailing list<br>
<a moz-do-not-send="true" href="mailto:Scip@zib.de"
target="_blank">Scip@zib.de</a><br>
<a moz-do-not-send="true"
href="http://listserv.zib.de/mailman/listinfo/scip"
rel="noreferrer" target="_blank">http://listserv.zib.de/mailman/listinfo/scip</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Scip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Scip@zib.de">Scip@zib.de</a>
<a class="moz-txt-link-freetext" href="http://listserv.zib.de/mailman/listinfo/scip">http://listserv.zib.de/mailman/listinfo/scip</a>
</pre>
</blockquote>
<br>
</body>
</html>