[Osi] About packaging OSI

[Stefan Vigerske]

Hi,

I do not see why you need an extra build of Osi for each solver. If you
build Osi with n solvers available, you get n+1 libraries: libOsi is the
common Osi stuff which is solver independent and required by any
specific Osi interface. Then you have for each solver a library
libOsiXxx which contains the interface to this particular solver.
If you add a C-wrapper around the constructor of each particular
OsiXxxSolverInterface (e.g., getNewOsiXxxSolverInterface()), and add
that into the libOsiXxx, then you could dlopen these libraries and get a
particular solver Xxx via getNewOsiXxxSolverInterface().
As Lou mentioned, there is also some reorganization of Osi and packaging
  in progress.

Stefan


Christophe-Marie Duquesne wrote:
> Hi,
> 
> I've been trying to use OSI on mainstream distributions and I always
> ended up installing it by myself. I'm dreaming about simply typing
> 'aptitude install osi' (or any equivalent with yum, emerge, pacman...)
> and getting what I want. That would indeed make the install procedure
> of my own programs much easier for the end user. However, things
> always go wrong, and though I once got a working osi configuration on
> my archlinux, it had only support for Clp. I was never able to get OSI
> and glpk working together this way.
> 
> For example, I'd like to be able to type 'aptitude install glpk
> osi-glpk' and have a version of osi working with glpk out of the box.
> Then when I get rich and I can afford cplex, I would simply type
> 'aptitude install osi-cpx', follow an installation procedure for cplex
> described in a wiki, and I'd be done. Unfortunately, to my knowledge,
> no distribution offers this kind of OSI packaging.
> 
> So, I'm seriously considering packaging OSI by myself. However, it
> does not seem that simple, because supported solvers are decided at
> compile time. So I was wondering: what is the right way to proceed?
> 
> Somehow, to package OSI properly, one would have to compile several
> versions  (OSI currently supports 12 solvers, so at least 12). I'm
> excluding compiling every possible configuration (imagine someone
> owning Clp, Glpk and Xpress, and someone owning Clp, Glpk, Xpress and
> Cplex, that would be two versions). I've come to think to a solution,
> but it is not very elegant: compiling one version of osi for each
> solver (that would support only this solver), and choose which version
> of osi should be used using environment variables. The user would
> install these versions with his packet manager.
> 
> # install osi with support for Clp, Cpx, Xpr would look like:
> aptitude install osi-common osi-cpx osi-xpr
> 
> After this, the end user configuration would end up looking like this:
> 
> /usr/lib/osi-clp/lib/libosi.so
>         |-/osi-cpx/lib/libosi.so
>         |-/osi-xpr/lib/libosi.so
> 
> Then before using a program using osi, he would type something like
> 'module load osi-cpx' (that's the way to do it in fedora) and his
> environment would then be set such that libosi.so is pointing to one
> in /usr/lib/osi-cpx/lib/libosi.so (the one that supports cplex)
> 
> The problem with this kind of configuration is that it would require
> programmers to rewrite their code a little, since this kind of switch
> would not be allowed anymore:
> 
>   string solverName = userInput();
>   OsiSolverInterface * osiPtr;
>   if (solverName == "Cbc") {
>     osiPtr = new OsiCbcSolverInterface();
>   } else if (solverName == "Cpx") {
>     osiPtr = new OsiCpxSolverInterface();
>   }
> 
> Instead, a library to handle the solver creation could be written and
> added to the OSI distribution. It would have an interface like this
> one:
> 
> // file OsiSolverInterfaceCreator.hpp
> class OsiSolverInterfaceCreator
> {
>   // returns the solver set by the user environment
>   OsiSolverInterface * getNewOsiSolverInterface();
> };
> 
> The programmer would include this file and following the user
> environment, getNewOsiSolverInterface() would return a solver or
> another one. The library corresponding to the header would indeed
> change according to the environment variable and return the right type
> of OsiSolverInterface.
> 
> Alternatively, one could write a library that still allows programmers
> to choose the solver dynamically, embedding dlopen() and dlclose() and
> loading the right library at run time:
> // file OsiSolverInterfaceCreator.hpp
> class OsiSolverInterfaceCreator
> {
>   // returns the solver specified by the string, opening the right
> library with dlopen/dlclose
>   OsiSolverInterface * getNewOsiSolverInterface(string solverName);
> };
> 
> I was not able to think about a solution that would force the
> developpers to change their code, but maybe there is one. So I'm
> asking this mailing list: Do you see a more elegant way to handle
> this? If you don't, do you think my proposition is acceptable? Are you
> interested in this attempt of packaging OSI?
> 
> Best regards,
> --
> Christophe-Marie Duquesne
> 06 84 14 26 82 - mobile
> 04 76 57 48 06 - g-scop
> 04 97 23 27 33 - amadeus
> 
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi
> 


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