Ask HN: Do you use an optimization solver? Which one? Do you like it?

I think Optaplanner has its own DSL, but we use the Java/JVM API: a 'solution' is just a normal JVM object, which references other objects in the usual way. Certain fields are annotated, which tells Optaplanner that it can mutate/alter them.

Implementing the domain objects is pretty natural. The only part that feels weird is that solving is completely based around mutation; whilst that's pretty idiomatic for Java, it feels a bit alien in Scala (I previously worked mostly in Haskell, and haven't written Java in over a decade).

There's a bunch of configuration boilerplate; including the following, which is the only Java code in the whole project (and almost looks like a parody of "Enterprise Java"!):

    class Config {
        public static ScoreDirectorFactoryConfig config =
            (new ScoreDirectorFactoryConfig())
            .withEasyScoreCalculatorClass(ScoreCalculator.class);
    }

IIRC, this had to be Java due to some weird self-referential interface that makes Scala's type-checker explode.

We can give each solution both a "hard" score and a "soft" score, where the soft score will be sacrificed if it improves the hard score. We use the hard score to count errors which make a solution invalid (e.g. trying to assign two people to the same seat); and the soft score as a weighted sum of mismatched seat attributes (e.g. it would be nice to stay facing the same direction; but not crucial).

Once the problem has been defined, it can be sent to a bunch of solvers; we use simulated annealing with a timeout. Since it's an anytime-algorithm, we can adjust the timeout to however long we're prepared to wait.

To avoid "obvious" problems in Optaplanner's results, we send them through a simple hill-climbing loop to ensure we're at a local maximum.

Great coverage — simulated annealing, genetic algorithms, ant colony optimization.

Yep, that'll do it. :) Thanks!

- Cplex and Gurobi, sometimes some open source ones.

- Energy modelling: the core models for one timestep are small (ca 1-2k variables), but together with long timescales/stochastic programming the model formulation blows up (easily by a factor of 10-40k).

- Mostly LP-relaxations of MILPs with manual cuts. MILPs themselves take often too long.

- The solvers are ok:

  - There is a nice theory around LPs and MILP is understandable. So in principle, I trea them as black boxes.

  - API: Similar enough between solvers because of nice formalism of MILP. Generic APIs on most platforms (pyomo, jump, ..). Beware magical helpers.

  - Performance: For LP predictable. For MILP -- tune it. It becomes tricky when tuning solvers/staying solver-independent without sacrificing performance. Metaheuristics to the rescue. Open source solvers have a harder time here.

- The big problem is the modelling and context part: translating the problem into am MP formulation, ensuring correctness of units/scales, generation of apis and docs ... once you do it by hand, but if you want to run a modeling loop or support multiple models (variants, optimisations, special cases), then this ist most of the effort (and costs human time, instead of computing time).

gurobi and cplex agree light-years ahead of the open source solvers. those will work on small problems, but you need the expensive ones for complex models.