[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