[Scip] Call to adjustedUb in SCIPvarChgUbOriginal causing solve failures
Gerald Gamrath
gamrath at zib.de
Thu May 12 18:43:19 MEST 2011
Hi Fergal,
thanks for the code snippet, when using it, we were able to reproduce
the problem.
It seems to be caused by a bug in Soplex when diabling the simplifier.
We are looking into the problem and will inform you when we know how to
fix it.
Best,
Gerald.
Am 10.05.2011 18:29, schrieb fergal mohan:
> 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
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
More information about the Scip
mailing list