can ecole use cplex/gurobi as options for LP solvers during the Branching process?

[stardustwls]

Describe the problem or improvement suggested

For some kinds of problems, the speed of ecole is too slow to do some deep research, especially the LP solver during the B&B process.

Describe the solution you would like

pyscipopt allow us to use cplex/gurobi instead of soplex as the LP solver, could you please tell us the possibility of solving this problem? Thanks a lot.

Describe alternatives you have considered

Additional context

[AntoinePrv]

The LP solver is controlled by your SCIP (the C library) installation. If you install SCIP with Cplex/Gurobi as the LP solver, then yes, I don't see why you wouldn't be able to. The Ecole code would remain the same.

For having different LP solvers in the conda-forge SCIP package, the package repo (that we co-maintain) is the proper place to discuss that. But given that Cplex and Gurobi are commercial, I don't see an easy way.

Disclaimer: We have not tested different LP solvers ourselves, let us know if you find bugs.

[samiit]

Hi,

I am glad to have been introduced to this package through the tutorial of Elias, and I was a bit surprised that it is so tightly tied to SCIP. Are there plans to include fully free and open-source solvers like HiGHS as the backend solver? Or else if you could share some basic pointers to integrate it, I (or some others) can give it a try.

Thanks, Sam

[AntoinePrv]

Are there plans to include fully free and open-source solvers like HiGHS as the backend solver?

As much as we'd like to, it is not feasible with the resources we have at the moment. Simply creating a common interface is both hard and limited (due to the differences between solvers). The existing C++ one Coin OR OSI is not complete enough for our use case.

The best interface that exists so far is Julia's MathOptInterface, but we made the choice to be Python fist (hence C++ for the library).

Or else if you could share some basic pointers to integrate it, I (or some others) can give it a try.

If you'd start from a completely different solver, I don't think starting from the Ecole codebase would not do you any good. We do believe however that our interface (with environment, reward function...) is a useful one to be reused in similar projects.

[gasse]

Hi @stardustwls , @samiit ,

There is an in-between alternative which works with Ecole in principle: interfacing with SCIP, but then exchange SCIP's default LP solver (SoPLEX) for another, more competitive LP solver (see a list here). I've recently tried using Gurobi's LP solver, it worked like a charm. What you have to do basically is to first compile the full SCIP Optimization Suite using CMake, with a specific LPS option to change the default backend LP solver. Then, with SCIP is properly installed and set-up, you can simply compile Ecole and Pyscipopt from source as follows:

# path to Scip installation
SCIPOPTDIR="$HOME/opt/scipoptsuite-7.0.3"

# path to where to put the compiled python packages (wheels)
mkdir -p $HOME/wheels

# set up a build virtual environment
virtualenv --no-download ./build-env
source ./build-env/bin/activate
pip install cython
pip install wheel
pip install numpy
pip install scikit-build
pip install cmake
pip install pytest
pip install pytest-helpers-namespace

# build PySCIPOpt
git clone git@github.com:scipopt/PySCIPOpt.git
cd PySCIPOpt
python setup.py bdist_wheel --dist-dir $HOME/wheels
cd ..

# build ecole
git clone git@github.com:ds4dm/ecole.git
cd ecole
python setup.py bdist_wheel --dist-dir $HOME/wheels
cd ..

# remove build environment
deactivate
rm -r ./build-env

Let us know if that helps,

Best, Maxime

[AntoinePrv]

@gasse if I may adjust: except whenusing conda, neither PySCIPOpt nor Ecole provide a libscip installation. They will find the one installed, whether it uses Soplex, Gurobi,... as an LP solver (understand it makes not difference for them). Hence regular install instruction apply for both PySCIPOpt and Ecole.

[gasse]

Thanks @AntoinePrv for adding those specifics. I'm never sure how / where libraries are loaded from, so I always recompile everything to be sure ^^

So what you mean is, if you have ecole or pyscipopt installed from pip, you can just switch between SCIP installations (changing PATH maybe ? ) and whenever you load ecole or pyscipopt from python they will use whichever version of SCIP you have available ?

[AntoinePrv]

if you have ecole or pyscipopt installed from pip, you can just switch between SCIP installations

Yes, if it is the same SCIP version.

changing PATH maybe

Either:

• Changing the actual libscip.so.X.Y.Z file
• Prioritizing a libscip by export LD_LIBRARY_PATH="/path/to/libscip/folder:${LD_LIBRARY_PATH}"
• Forcing a specific library by export LD_PRELOAD="/path/to/libscip.so"

⚠️ I don't know the priority rules for loading libraries (it depends on a lot of things). Depending on how pyscipopt and ecole are installed, they may also contain a builtin path that may have higher priority than LD_LIBRARY_PATH. In that sense, it could be useful to recompile to be sure that builtin path points to the given installation, but then you need to make sure you point to the correct SCIP installation at compile time. Bottom line, if you have multiple SCIP installations, you need to know what you're doing.

whenever you load ecole or pyscipopt from python they will use whichever version of SCIP you have available

Yes, in fact you can statically see which one will be loaded with ldd <ecole_root>/ecole/core.*.so on Linux, where you can find <ecole-root> with python -m pip show ecole | grep Location