[Scip] Call to adjustedUb in SCIPvarChgUbOriginal causing solve failures
fergal mohan
fergal at mohandigital.com
Wed May 4 12:09:38 MEST 2011
Hi guys, thanks for the replies which helped me focus my deeper digging, Just
for the record I am calling the SCIPchgVarUb() method which in turn calls
SCIPvarChgUbOriginal(). First a little background that might help with context
and hopefully might lead to an appropriate workaround for my problem. My .NET
abstracts the LP and MIP solving so that the end user is not encumbered with
having to manage those details. The end user can load a problem with no fixed
integers solve it, fix some variables as integers solve again etc. Under the
hood the .NET layer copies the problem between Soplex and SCIP Models and does
the right thing for the user.
The problem I'm seeing (thanks in part to Gerald's suggestion about Soplex) in
the latest version is that when the upper bound gets rounded down to 1e20 and
the end user "unfixes" the integers that upper bound gets copied back into
Soplex and the solve fails. I wrote a little test to verify that failure is
happening when solving after reading in the sample content below i.e. I use
SCIPlpiReadLP() to read in 2 versions, the first with the upper bounds set to
1e+0100 solves fine (50.0) and the second with the upper bounds set to 1e+020
doesn't (0.0).
I realize that there is probably a legacy reason for SCIP_INFINITY being 1e+020
and DEFAULT_INFINITY (for Soplex) being 1e+0100 but I'd like to get back to the
point where I can copy these upper bounds back and forth between Soplex and SCIP
with impunity. Can I safely comment out adjustedUb in SCIPvarChgUbOriginal or
should I reverse it's actions by rounding any 1e+020 back up to 1e+0100 (and
similarly for negative infinity) when I am doing the copying between Models ? I
think that latter would be less likely to have fallout but would appreciate any
thoughts from the community on this matter, regards, Fergal
>> These upper bounds work
Maximize
obj: 28 x0 + 11 x1
Subject To
C1 : 14 x0 + 6 x1 <= 25
Bounds
x0 <= 1e+0100
x1 <= 1e+0100
End
>> These upper bounds don't
Maximize
obj: 28 x0 + 11 x1
Subject To
C1 : 14 x0 + 6 x1 <= 25
Bounds
x0 <= 1e+020
x1 <= 1e+020
End
----- Original Message ----
From: Gerald Gamrath <gamrath at zib.de>
To: scip at zib.de
Sent: Tue, May 3, 2011 1:27:15 PM
Subject: Re: [Scip] Call to adjustedUb in SCIPvarChgUbOriginal causing solve
failures
Hi Fergal,
SCIP has its own infinity value, which is per default 1e+20. Every
number larger than that is treated as infinity and just set to 1e+20. If
you really need larger numbers, you have to change the SCIP parameter
"numerics/infinity" to something larger, but actually, 1e+98 is the
highest possible number. As far as I know, the infinity value in SCIP
was always 1e+20, so it should not have worked in older versions,
either. Perhaps you mixed it up with Soplex, where the infinity value is
1e+100?
Besides, the method SCIPvarChgUbOriginal() is for internal use only. You
should only use methods stated in scip.h and pub_*.h. The correct method
would be SCIPchgVarUb(), given in scip.h, which - depending on the stage
of SCIP - also changes the original bound (when you are in the problem
creation stage). In all other stages, you must not change the original
bound, anyway.
Best,
Gerald
Am 03.05.2011 13:32, schrieb fergal mohan:
> Hi all, I've recently updated the Microsoft .NET wrapper that I wrote a couple
> of years ago to allow .NET Applications so that it could be used SCIP 2.0 and
> Soplex 1.5. I restructured the projects to use the new Developer Studio
>Solution
> files that were made available (thanks Wei Huang) and after fixing up a few
> things that I was expecting all seems to be working as expected apart from one
> problem. When I try to set an upper bound using SCIPvarChgUbOriginal() to
1e100
> the new call to adjustedUb() overrides the incoming value and restricts the
> upper bound to 1e20. This causes my previously working solve to now fail. I'm
> not sure if it's a case that I have previously been relying on something that
> was incorrect in the older versions or if this is a "real" issue with the
> current SCIP version. I can supply more details on my test if it helps but at
> the macro level I just wanted to first check with the the mailing list
>colective
> wisdom as to whether the adjustedUb() interaction is kosher? Any insights out
> there ?
> Fergal
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
_______________________________________________
Scip mailing list
Scip at zib.de
http://listserv.zib.de/mailman/listinfo/scip
More information about the Scip
mailing list