Speed dating with LocalSolver

This post records my observations and comments after my first evening using LocalSolver, a solver based on the local search paradigm rather than on the branch-and-cut framework common to most MIP solvers. Overall, my first contact with LocalSolver was quite positive. This is a very general review, as its performance and features will be reviewed in more detail in an upcoming post.

First Observation: Simple

The first thing that struck me while installing and trying to run my first model is how simple it was. LocalSolver can be downloaded, activated and installed through simple steps. In fact, it installs like Gurobi’s solver. The support page lands you directly on the Quick Start Guide, and that page is very well written. I started by using the interactive console, which is always what I do when I try a new solver. To give you an idea of how simple it is to use, here are the steps I followed:

  1. Read the Quick Start Guide and the “Solving your first model” section.
  2. Ran the Knapsack example;
  3. Using the provided example, I built a template (lsp file) to solve single-stage and two-stage facility location models.
  4. Generated toy instances for each and ran them through LocalSolver.

The whole process took about one hour. The modeling language is simple, straightforward and easy to understand and use. Its limitations are well described and quite understandable for a new product. The fact that you don’t have to define anything related to the search process (neighborhoods and operators, for those who are familiar with local search techniques) is quite significant. It basically guarantees that using localsolver will be easier than implementing your own local search code, even when using code libraries or templates such as ParadisEO.

Second Observation: Fast

Aside from being simple, LocalSolver is also fast. By fast, I mean that LocalSolver performs a lot of search operations (moves, in the local search terminology) per second. It is probably slightly faster than a tailored code done by a typical academia in terms of search speed (but not necessarily search effectiveness, that remains to be analyzed). Because local search techniques offer no optimality guarantee, you cannot measure performance in terms of “times to optimality” unless the optimum to your model is already known. Speed can be a drawback while using generic codes, and LocalSolver is not affected by this bane. The console version of LocalSolver also displays some information about search state at each second.

But wait! There’s more…

I also want to congratulate the team that launched LocalSolver and maintain it to this day.  Regardless of one’s opinion of this product, it takes some guts to go against established leaders such as IBM (CPLEX) or Gurobi. Bo Jensen (Sulum Optimization) and all other small businesses deserve the same kind of praise. Having started a business myself a few years ago (which we closed down when I came back to school to start my Ph.D.), I know a little bit about the tremendous task of simultaneously developing and promoting your product while doing consulting work so as to keep the business going.

My next post will investigate LocalSolver’s performance.

Trackbacks

  1. […] whether LS is able to find good solutions quickly and reliably. This post is a follow-up of my first experiments with LocalSolver; I encourage you to read this if you didn’t do so already. The dual post describes what are […]

Speak Your Mind

*