Announcement: Huub v100.0.0 – a new CP+SAT MiniZinc solver

[Jip Dekker]

Dear MiniZinc community,

I am excited to announce the first public release of a new MiniZinc solver: Huub.

Huub is a CP+SAT solver written in Rust. It is designed to work as a MiniZinc backend, so existing MiniZinc models can be run with Huub through the usual MiniZinc workflow. Huub achieved 3rd place in the 2025 MiniZinc Challenge, and the solver is now available for others to try.

If Huub works well on your MiniZinc models, you may also want to use it as a Rust framework to integrate solving more tightly into your application. In that setting, the solving can be customized much more heavily than through the MiniZinc interface alone.

Some technical details:

• Huub uses an IPASIR-UP based architecture, enabling different underlying SAT solvers.

• It provides access to modern SAT features, currently through CaDiCaL.

• It is designed as an extensible Rust framework, allowing users to add their own propagators and branchers, as well as implement custom (meta-)search algorithms via its incremental interface.

The version number 100.0.0 is a one-off milestone: Huub is named after my grandfather, who would have turned 100 this year. From here on, Huub will follow semantic versioning.

More information:

• Website: https://huub.solutions

• MiniZinc solver package: https://github.com/huub-solver/huub/releases/

Feedback from MiniZinc users would be very welcome, especially reports on models that work well or do not solve as expected.

Many thanks to the other project members, Allen Z. Zhong and Peter J. Stuckey, and to everyone who contributed along the way.

Cheers,
Jip J. Dekker

[Erik Cervin Edin]

Great news!

On 26/05/14 04:22AM, 'Jip Dekker' via MiniZinc wrote:
> Huub achieved 3rd place in the 2025 MiniZinc
> Challenge, and the solver is now available for others to try.

Any sense on how much has changed in performance since last year?

> If Huub works well on your MiniZinc models, you may also want to use it as
> a Rust framework to integrate solving more tightly into your application.
> In that setting, the solving can be customized much more heavily than
> through the MiniZinc interface alone.

Any interesting knobs which can be tweaked when running which are worth
knowing about?

Can't wait to give this solver a serious try!
I remember Danyal running some benchmarks on a model and seeing some
very promising results.

Great work Jip, Allen, Peter and others!

[Paul Chisholm]

Hi Jip,

I have been trying out Huub and it looks good. Will it eventually be incorporated into MiniZinc release packages?

I sometimes see the following warning from the solver:

0.001560042s WARN flatzinc: ignore unsupported constraint annotation annotation=domain constraint=int_lin_eq

I have no knowledge of what goes on behind the scenes but I'd be interested to know what causes this. The solution is always correct. Below is a minimal model that elicits the warning

set of int: ROW = 1..3;set of int: COL = 1..3;
enum track_piece = {ns,ew,ne,nw,se,sw};
array[ROW] of COL: row_counts = [1,2,2];
set of int: PATH = 1..sum(row_counts);
array[ROW,COL] of var opt track_piece: solution;
array[PATH] of var ROW: pathr;array[PATH] of var COL: pathc;
constraint forall(p in PATH)(occurs(solution[pathr[p],pathc[p]]));

[Jip Dekker]

Any sense on how much has changed in performance since last year?

 

There has been a lot of development since last year's challenge, but admittedly, they have focused on specific model types (such as the merging of Danyal's non-overlapping/diffn_k propagator), stability, and ease of use. It is hard to say how this would translate to the performance in general in the context of for example the MiniZinc challenge. We have some ideas for further advancements that we hopefully can implement before this year's MiniZinc challenge.

Any interesting knobs which can be tweaked when running which are worth knowing about?

With custom propagators, branches, and search, you can really change a lot about the solver. However, you can tweak just using options as well, and we do expose some of the most impactful options from MiniZinc (see `huub --help`).

I have no knowledge of what goes on behind the scenes but I'd be interested to know what causes this. The solution is always correct. Below is a minimal model that elicits the warning.

The warning is only to caution the user that there was an annotation placed (in MiniZinc) on a constraint that Huub couldn't handle. The idea being that, even though it is correct to ignore the annotation, the user would likely want to know when something they write in a model is being ignored.

In this case, the `occurs` constraint is translated through array_var_bool_element_nonshifted, where the standard library request a domain consistent linear constraint. Since Huub doesn't implement this, it issues the warning. The main issue here seems to be that the user doesn't really influence the presence of this annotation.

Thank you for raising the issue, I will investigate to determine what the best option is to remedy this.

Cheers,

Jip

--
You received this message because you are subscribed to the Google Groups "MiniZinc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minizinc+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minizinc/efef7daa-5606-4790-b798-91773ebbb260n%40googlegroups.com.