[Scip] Is using a subset of SCIP (e.g. B&B) possible to extend Soplex capabilites for limited MIP functionality?

fergal mohan fergal at mohandigital.com
Fri Jul 3 14:16:56 MEST 2009


Hi Tobias, hopefully I can make the .NET wrapper public after an intial exclusive rights period expires.
Your reply has thrown my plans into a bit of a tailspin (especially the part about a plugin which might be a stretch for me ;-)
Forgive me (I'm not a subject matter expert by any means) for digging deeper but it might have a big impact on my plans if I don't have a good understanding of my options.
>From an overall architecture POV I'd like to provide a common interface (i.e. a common .NET interface for LP and MIP) and add an abstraction layer to perform any SCIP/Soplex specific handling behind the scenes.
I'd prefer if I could to develop an initial version treating SCIP as a black box MIP solver. In terms of LP solving AFAICT I can either use Soplex as I currently am or use SCIP to solve the LP problem and expose access (in my .NET wrapper) to the built-in Soplex Solver so I can retrieve the solution data (like dual variables, reduced costs or basis information). I can live with having to copy the problem to SCIP if integer constraints are introduced changing the problem from an LP to an MIP. 
Does this sound viable or am I missing something fundamental that would neccessitate a plugin ?
Fergal

--- On Thu, 7/2/09, Tobias Achterberg <achterberg at zib.de> wrote:

> From: Tobias Achterberg <achterberg at zib.de>
> Subject: Re: [Scip] Is using a subset of SCIP (e.g. B&B) possible to extend Soplex capabilites for limited MIP functionality?
> To: "fergal mohan" <fergal at mohandigital.com>
> Cc: scip at zib.de
> Date: Thursday, July 2, 2009, 12:06 PM
> fergal mohan wrote:
> > Hi guys, thanks for helping me tease out the details.
> I'm actually providing (Managed)
> > C++ interface methods so that any .NET language can
> use the Solvers. I suspect that I
> > can access the Soplex LP data (like dual variables,
> reduced costs or basis information)
> > directly, even if I've used SCIP to setup the LP. In
> terms of the optimal design I'm
> > inclined to start using SCIP for MIP and I'll see if I
> can make a conditional compile
> > to build it eaither way (SCIP or Soplex only) for LP.
> I might be able to answer the
> > overhead questions if all goes according to plan. Let
> me know if there is any more
> > related wisdom on this, cheers, Fergal
> 
> This is great to hear that you are working on a .NET
> interface. Do you have plans to make
> this public?
> 
> Regarding the LP solver interface, I don't think that
> mixing SCIP and Soplex stuff is a
> good idea. They just have completely different interfaces
> and ways to store the problem
> data. I would implement two separate wrappers, one for SCIP
> (with MIP capabilities) and
> one for Soplex (with LP capabilities). Neither is a subset
> of the other. Soplex misses
> integrality restrictions, SCIP is missing simplex
> information query methods like dual
> solution values and basis information.
> 
> In this sense, SCIP+Soplex is really different from CPLEX.
> As you may know, in CPLEX you
> can specify the problem with common interface methods, and
> it just depends on whether you
> have a 'ctype' (integrality information) or not that
> decides whether the problem is an LP
> or MIP. But similar to SCIP, if it is a MIP you cannot
> query duals or basis information
> after having solved the problem.
> 
> As an example, consider a heuristic that solves a series of
> LPs and queries simplex
> specific data. Eventually, it wants to declare some of the
> variables to be integer and
> solve a MIP. This is very easy to do with CPLEX but hard to
> do with SCIP+Soplex. For
> SCIP+Soplex, in order to solve a MIP you need to copy the
> whole problem from Soplex into SCIP.
> 
> Actually, such an algorithm in SCIP would better be
> implemented as a SCIP plugin, which
> then uses SCIP's LP relaxation (which in the end will be a
> Soplex or any other LP solver
> object) to fiddle around with LP stuff.
> 
> 
> Tobias
> 


More information about the Scip mailing list