[Scip] scaling

[Tobias Achterberg]

Tamas Mahr wrote:
> On Wed, 26 Nov 2008 20:45:18 +0100
> Tobias Achterberg <achterberg at zib.de> wrote:
> 
>> No, you are completely right. The SoPlex class is basically a wrapper
>> around the core SPxSolver class to provide presolving and scaling.
>>
>> However, this is not as easy as it seems. I don't know whether SoPlex
>> already supports all the calls that are needed for SCIP, for example
>> to access the simplex tableau rows (and automatically unscale it).
> 
> I have tried to make a new SPxSCIP class that builds on SoPlex, but I
> ran into this problem you mention above. SoPlex stores the problem
> internally, but when it comes to solving it, it copies the problem into
> an SPxSolver object and makes that solve it. Now when various SCIP
> functions are trying to access the solver internals, it only makes
> sense to access the solved problem withing the SPxSolver that is used
> by SoPlex, and not the problem stored in SoPlex itself. But of course
> SCIP expects an unscaled, unsimplified problem, and I was wondering if
> it is possible to transform such internal representations as the
> simplex tableau back. My bet was that it is not
> possible. Actually, comments in the simplifier class (call it
> documentation) suggests that it is not possible to undo the changes. It
> is only possible to transform the solution to the simplified problem
> into a solution to the original problem. So I got stuck here,
> concluding that maybe SCIP should not access the internals of the
> solver, maybe the solution should be enough. But then, I do not really
> know the reasons why it is necessary, so I leave it up to you. :)

The main reason is Gomory cuts. These cuts need access to the simplex tableau. The other 
"advanced" LP feature that SCIP needs is to get primal and dual rays in the case of 
unbounded or infeasible problems.

But fortunately, I think that the main obstacle for not using SoPlex is the simplifier. 
This really makes it complicated to access advanced stuff in a transparent way. The scalar 
should be much more simple - you just need to unscale all data, which should always be 
possible.


> I would like to thank Thorsten too, and as he suggested, I will wait
> for the next release. :)

That's also my suggestion. If you really need to solve your problem instance, and if these 
numerical issues are not only an exception, then you can consider using SCIP/Clp.

The better alternative, however, is to generate your models in a way such that they do not 
need scaling. This would also improve the numerics inside SCIP. Maybe, you can reformulate 
the model (like adjusting your scale, for example talking about millions of dollars with 
continuous variables instead of cents in general integers).



Tobias