5
$\begingroup$

For a side project, I'm looking to install COIN-OR project solvers on a Microsoft Azure Ubuntu VM. (I will be running Pyomo optimization models on this VM as well; using NEOS isn't cutting it.) Anybody have any experience in installing these solvers on Unix-like machines? Any advice? Right now my plan is to google and indiscriminately copy-paste command line statements.

Progress thus far is crossposted to https://stackoverflow.com/questions/56618861/solver-did-not-exit-normally-jupyter-python3-ubuntu

$\endgroup$
  • 4
    $\begingroup$ Based on this answer on meta, I would say that this question is out of scope for OR.SE and should be posted on SO. What do others think? $\endgroup$ – LarrySnyder610 Jun 14 '19 at 1:41
  • 6
    $\begingroup$ Questions about software installation or software development are off-topic here, but can be asked on Stack Overflow. $\endgroup$ – Marcus Ritt Jun 14 '19 at 2:06
  • 5
    $\begingroup$ I figured this was fairly appropriate for OR SE since there aren't many regular SO users who will have experience with using Pyomo and COIN-OR. Also as an industry practitioner of OR, installing / configuring specialized OR software is something my coworkers and I deal with with some regularity. At any rate, googling did the trick (mostly). $\endgroup$ – Ralph Jun 14 '19 at 11:40
  • 2
    $\begingroup$ To @MarkL.Stone's comment -- remember, folks, that a downvote means "sloppy, poorly researched, etc." To indicate "off-topic", use vote to close instead. (If you feel it's both, then cast both votes, of course.) $\endgroup$ – LarrySnyder610 Jun 14 '19 at 11:59
  • 3
    $\begingroup$ Well, googling did mostly work... but the remaining portion is something where I can find very little useful tidbits online. This is a case where I think that allowing software questions in OR SE will be very useful. $\endgroup$ – Ralph Jun 14 '19 at 22:20
3
$\begingroup$

I do not have direct experience myself with installing COIN-OR solvers under unix-based operating systems, but I do know that it can be done.

I have seen it successfully done for CLP (Linear Program Solver) and CBC (Branch and Cut Solver) by directly downloading the (open) source code and integrating these libraries with other source code. This is the approach I personally would take.

Having said this, there are binary distributions. See

https://projects.coin-or.org/CoinBinary

and for Debian based systems (such as Ubuntu) see

https://projects.coin-or.org/CoinBinary/wiki/CoinDeb

Ralph, I would be interested in hearing about how you went and about what information you were able to find out.

| improve this answer | |
$\endgroup$
3
$\begingroup$

The Coin-OR stack is pretty complex with a huge dependency chain.

In general i would say, that the usual rules apply: easiest to hardest in general looks like

  1. System Packages
  2. Official Builds
  3. Build from Sources

In all cases it might be critical if someone only needs an executable (probably sufficient for pyomo) or a shared library (often easier to obtain the first; and always easier to provide some software to call the binary instead of linking or loading shared libs).

1. System Packages

This boils down to recognizing ones system and it's package-repositories. Then check is pre-made builds are available.

The usual cli-commands like lsb_release -a and the GUI-based package-managers can help.

For Coin-Cbc for example, one would find those.

2. Official Builds

It's sometimes not trivial to find those builds (and CoinOR is no exception in terms of competing documents where some are outdated and some are not). You will eventually see dead links (or 5 years old builds) trying to follow the links in Mark's answer: CoinBinary.

I would start with some of the development-places. While maybe not the core-dev place, Coin Cbc's github page for example links to this bintray providing builds.

3. Build from Sources

If there would be one thing i learned from the past it would be: CI can be a blessing! Exploit this.

Example

Let's give you some example with CHiPPS-BLIS. We want to develop something with it and therefore need our environment ready to link against it. It might be a good idea to build the current version from source and make use of it's makefiles for our work too (which is another terribly complex thing).

We start with above github entry and find Install.md:

We learn:

  • There is an extra project available just for handling Coin-OR installs / dependency management / builds: COIN-OR-OptimizationSuite
  • This route is recommend in the Install.md

But we will shortly recognize the outdated nature as:

./coin.install.sh fetch build --no-prompt --main-proj=Blis

will not do.

Now: outdated documentation is very common. But here there is a cure (and this covers most Coin-OR projects): Continuous Integration.

The main-page will show you some CI-buttons under section TESTING STATUS and it's green, so how hard can it be?

We might follow this one and arrive at some Travis-CI build.

Now we can emulate what's been done there and this case: we directly see the problem from before:

export PROJECT=`echo $TRAVIS_REPO_SLUG | cut -d "/" -f 2`
./coin.install.sh fetch --no-prompt --main-proj=$PROJECT > /dev/null

-> either one tries to understand the export syntax or one restrict to guessing
-> it's just the name within the travis-address:
    -> https://travis-ci.org/coin-or/CHiPPS-BLIS/jobs/506947381)

CHiPPS-BLIS is the project name needed for COIN-OR-OptimizationSuite

Blis (as mentioned in Install.md) is not used (and won't work)!

Now there are other important things in those build-logs helping to make something work. We see for example which version is checked out (and guaranteed to build assuming we got the same sane system) and some dir-change order to follow.

In general, these CI-scripts, when maintained, really seems to help and i won't miss out on these in the future. The above was some Coin-focused example, but recently, i again failed following official install guides and made it work following CI with Google's or-tools (Coin deps, Protobuf deps and co.).

I think it's safe to assume, that outdated documentation is more common than failed and unhandled CI-checks which will result in some ugly broken flags (and usually E-Mails).

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.