[Scip] Call to adjustedUb in SCIPvarChgUbOriginal causing solve failures

fergal mohan fergal at mohandigital.com
Tue May 10 18:29:24 MEST 2011


Hi Gerald, I figured that the most optimal way to help answer what is going on 
would be to map the calls that my .NET wrapper makes down to the SCIP calls. 
I've managed to distill it down to the following routine that demonstrates the 
problem. Reading in the testCopyBad.lp file (which has the upper bounds spec'ed 
as <= 1e+020) fails with result 0.0. If you replace that filename with 
testCopyGood.lp (which is as I described earlier (see below for old email 
message) with upper bound  <= 1e+0100) solves correctly with result = 50.0.
I'm using the latest versions that I downloaded (Soplex 1.5 and SCIP 2.0.1) and 
I'm also using the Microsoft Project files (ziboptsuite.sln et al). Maybe you 
won't see the same if you are on a different environment (I'm running on Window 
and compiling with Visual Studio 2008) but if you can repro the failure please 
let me know, cheers,
Fergal

int TestLpiReadProb()
{
        SCIP_CALL_EXC( SCIPlpiCreate(&pMySCIP_LPI, "lp", SCIP_OBJSEN_MAXIMIZE) 
);
        if(pMySCIP_LPI)
        {
            SCIPlpiReadLP(pMySCIP_LPI, "c:\\data\\temp\\testCopyBad.lp");
            SCIPlpiSolvePrimal(pMySCIP_LPI);            // calls SCIPsolve
            double dObjValue = 0.0;
            SCIPlpiGetObjval(pMySCIP_LPI, &dObjValue);    //
            std::cout << "Result is " << dObjValue << std::endl;
            // free the Prob
            SCIPlpiFree(&pMySCIP_LPI);

        }    // ENDIF pMySCIP_LPI        
    return 1;
}




----- Original Message ----
From: Gerald Gamrath <gamrath at zib.de>
To: scip at zib.de
Sent: Mon, May 9, 2011 5:16:27 PM
Subject: Re: [Scip] Call to adjustedUb in SCIPvarChgUbOriginal causing solve 
failures

Hi Fergal,

first of all, we ran both models that you stated below with soplex as 
well as with scip and all four times, the computed optimal solution 
value was 50.
However, we are not sure whether you intended the variables to be 
non-negative? While it is not stated in the model, the lp-format 
implicitly assumes nonnegativitly unless another lower bound is given.
As long as the variables are non-negative, the variables should always 
have small values and the infinity value should not matter.

When you run your code, do you get an error when solving the second 
instance or just the wrong result? Can you reproduce it by just calling 
soplex for the second instance? If yes, could you tell us the version of 
soplex you are using?

You should NOT comment out adjustedUb in SCIPvarChgUbOriginal. What you 
can do is change the infinity value of SCIP to something higher. But as 
I mentioned before, 1e+100 is not possible. My suggestion would be to 
change the infinity value of soplex to 1e+20, or adjust both infinity 
values to something in the middle. Do you really have instances where 
variables get such high values that the inifinity value gets important?

By the way, in case the variables should have no finite lower bound, the 
optimal objective value of the problem changes depending on the infinity 
value. However, in this case, the problem is unbounded, anyway, so the 
computed solution is not optimal, but just bounded by the infinity value 
which has nothing to do with the problem.

I hope, this helps a bit, if you have any more questions, just ask them.

Best,
Gerald

Am 04.05.2011 12:09, schrieb fergal mohan:
> 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
>
> _______________________________________________
> 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