[Osi] About packaging OSI

[Stefan Vigerske]

Hi,

if developers wanna have the feature of being able to check at run time
which interface is available, then small changes in their code should be ok.
E.g., instead of having whole OsiXxxSolverInterface stub codes, you may
have only a set of C functions like
  OsiSolverInterface* getNewOsiXxxSolverInterface();
which are implemented to return NULL if the corresponding
OsiXxxSolverInterface() is not available.
Or you have a function
  OsiSolverInterface* getNewOsiSolverInterface(const char* name)
that returns an interface to the solver with that name.
These C function should check either at run time whether the
corresponding libOsiXxx.so is available and dlopen() it, or it is setup
at build time.
I am not so sure, where to put this layer yet. It may not be libOsi, but
maybe an additional library, since it somehow need to have knowledge of
all possible OsiXxx.

Inside the libOsiXxx, one could implement another simple C function
  OsiSolverInterface* getNewOsiXxxSolverInterface();
which just returns a new OsiXxxSolverInterface().
This function could then be used by someone who dlopen()'s this
libOsiXxx.so, e.g., the additional library mentioned in the previous
paragraph. It will become more involved if you wanna pass arguments to
the constructor, though.

I don't know, still sounds a bit confusing ;-).

Also I'm not sure how to handle the linking against the right solver
libraries (libClp, libcplex121, libgurobi30,...).

Stefan

PS: Ipopt has a similar feature called linear solver library loader (or
something shorter), which allows the user to load a linear solver (MA27
or Pardiso) at runtime. It should work at least on Linux and Windows
systems, so one may copy the library loader from there.

Christophe-Marie Duquesne wrote:
> Hi Stefan,
> 
> You are perfectly right, the solution I proposed was too
> straightforward. Yours makes more sense.
> 
> I am still wondering if there is another way to do this, because this
> kind of packaging would oblige the developpers using Osi to adapt
> their code, replacing 'new OsiXxxSolverInterface' with
> 'getNewXxxSolverInterface'.
> 
> For example, I wonder how difficult it would be to package stub
> solvers: fake libraries that would define the same symbols used by
> each OsiXXX and link correctly, but that would do nothing when called
> (they would throw an exception or something). The packager would be
> enabled to deliver a unique version of Osi compiled with support for
> every solvers, using the stubs solvers as dependencies, and actually
> installing one of these solvers would be equivalent to replace its
> stub library with the actual solver. I think that would also do the
> trick and prevent any modification in Osi client codes.
> 
> Now I don't know if it is really worth the effort: generating a stub
> library can be tricky if OSI makes use of a lot of symbols of the one
> to be replaced. The first solution seems easier to apply, which is a
> really important point for me since we can get quickly to something
> that works.
> 
> Lou:
> 
> I am having a look at your scripts. I was not aware of the ongoing
> effort to package OSI. I would love to contribute. I'll try to update
> myself and will come with questions asap.
> 


-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan