Hexaly solver integration with MiniZinc

[Andrea Rozaki]

Hi MiniZinc team,

I’m interested in integrating the Hexaly solver with MiniZinc because I often compare the same models across Gurobi, OR-Tools CP-SAT, and Hexaly.

From the handbook section on Interfacing Solvers to FlatZinc (FlatZinc / FlatZinc-JSON + .msc config), it looks like the “standard” integration path is a FlatZinc(-JSON) solver interface. However, Hexaly’s documentation/CLI seems to focus on its own modeling formats/APIs and I couldn’t find any mention of FlatZinc / MiniZinc support (so I assume it’s not FlatZinc-native).

Questions:

1. Is Hexaly integration something already being discussed or worked on anywhere in the community?

2. If not, what would you recommend as the fastest/cleanest approach for an initial integration?

   • An external FlatZinc-JSON wrapper (via inputType=JSON in an .msc file) that translates supported constraints to Hexaly and prints standard MiniZinc output?

   • Or a deeper libminizinc backend approach assuming that makes sense for Hexaly?

3. Are there example repos / existing solver wrappers (especially FlatZinc-JSON based) you’d point to as a reference implementation?

I’d be happy to build an experimental integration (starting with a small supported subset) to explore whether this approach makes sense

[Jip Dekker]

It would indeed be very exciting to have Hexaly available as a MiniZinc solvers. Although we have briefly discussed this in the past, we haven't started the process yet.

Whether Hexaly FlatZinc interface would work better as a FlatZinc-JSON reading executable or deeply integrate depends a lot on how Hexaly works (and I haven't looked into this enough). I think there are two important reasons why a solver like Gurobi has an integrated interface. The foremost consideration is that MIP solvers receive some special handling to improve their performance. They also produce countless granular constraints, making the printing to FlatZinc (JSON) a bottleneck. (I'm actually working on a different external solver interface that would avoid this bottleneck).

The second is that it provides an easier way to deal with the licensing of the solver. Having an advanced interface that knows where to find Gurobi and dynamically loading it allows us to make it much easier to use Gurobi with MiniZinc. Users just have to have a Gurobi licence and install it, and MiniZinc does the rest. Importantly, we do not need users to compile a special version of MiniZinc (or a solver interface) depending on whether they have a Gurobi licence, and we do not distribute proprietary code. However, we recently discussed that similar approaches could certainly be possible in a FlatZinc executable.

In general, my recommendation would be to start as a separate FlatZinc (JSON) executable and work from there, unless there are some special considerations.

When it comes to examples, I have written a Rust crate called "flatzinc-serde", that can help parsing the FlatZinc JSON spec in Rust. I have used this to implement the FlatZinc interface for the Huub solver. The FlatZinc JSON is read here: https://github.com/huub-solver/huub/blob/develop/crates/huub-cli/src/lib.rs#L215-L240. And it is then processed in the module here: https://github.com/huub-solver/huub/blob/develop/crates/huub/src/model/deserialize/flatzinc.rs.

Hopefully, this might help you get started. I'd be happy to assist further if you run into any problems.

Cheers,

Jip

[Andrea Rozaki]

Thank you very much for the prompt answer! I will then working with a separate FlanZinc executable and get back to you in case there is any issues