The minizinc tool can use various solver backends for a given model.
Some solvers are separate executables that are called by minizinc and passed the name of a FlatZinc file;
other solvers are part of the minizinc binary (either hard-coded or loaded as a dynamic library or “plugin”).
Some solvers are part of the binary MiniZinc distribution, others have to be installed separately.
You can find instructions for installing these solvers from source code and integrating into the minizinc tool
in Installation from Source Code.
This chapter summarises usage options available for various target solvers.

The help text of minizinc shows a list of configured solver backends and their tags. You can see solver-specific command-line options by running

Gecode is an open-source constraint programming system (see https://www.gecode.org).
It supports many of MiniZinc’s global constraints natively, and has support for integer, set and float variables.

Gecode supports a number of constraints and search annotations that are not part of the MiniZinc standard library.
You can get access to these by adding include "gecode.mzn"; to your model. The additional declarations are documented in Section 4.2.7.

Chuffed is a constraint solver based on lazy clause generation (see https://github.com/chuffed/chuffed).
This type of solver adapts techniques from SAT solving, such as conflict clause learning,
watched literal propagation and activity-based search heuristics, and can often be much faster than traditional CP solvers.

In order to take full advantage of Chuffed’s performance,
it is often useful to add a search annotation to the model (see Search),
but allow Chuffed to switch between this defined search and its activity-based search.
In order to enable this behaviour, use the -f (free search) command line option or
select Free search in the solver configuration pane of the MiniZinc IDE.

Chuffed supports a number of additional search annotations that are not part of the MiniZinc standard library. The additional declarations are documented in Section 4.2.8.

OR-Tools is an open-source CP/SAT/LP solver (see https://developers.google.com/optimization/).
It supports many of MiniZinc’s global constraints natively. It often performs better multi-threaded (option -p)
so it can employ various solving technologies. A search annotation (see Search) can be useful.

MiniZinc has built-in support for Mixed Integer Programing solvers. If you have any MIP solver installed (and MiniZinc was compiled with MIP support), you can run a model using MIP like this on the command line:

minizinc --solver mip -v -s -a model.mzn data.dzn

Of course, you can also select a particular solver, e.g. Gurobi (in case it is available):

Avoid mixing positive and negative coefficients in the objective. Use ‘complementing’ variables to revert sense.

To avoid numerical issues, make variable domains as tight as possible (compiler can deduce bounds in certain cases but explicit bounding can be stronger).
Try to keep magnitude difference in each constraint below 1e4.
Especially for variables involved in logical constraints, if you cannot reduce the domains to be in +/-1e4,
consider indicator constraints (available for some solvers, see below), or use the following trick:
instead of saying b=1->x<=0 where x can become very big, use e.g. b=1->0.001*x<=0.0.
Especially for integer variables, the domain size of 1e4 should be an upper bound if possible – what is the value of integrality otherwise?
Avoid large coefficients too, as well as large values in the objective function. See more on tolerances in a below section.

Example 1: basic big-M constraint vs implication. Instead of <expr><=1000000*y given var0..1:y
and where you use the ‘big-M’ value of 1000000 because you don’t know a good upper bound on <expr>, prefer y=0-><expr><=0
so that MiniZinc computes a possibly tighter bound, and consider the above trick: y=0->0.0001*<expr><=0.0 to reduce magnitudes.

Example 2: cost-based choice. Assume you want the model to make a certain decision, e.g., constructing a road, but then its cost should be minimal among some others, otherwise not considered. This can be modeled as follows:

var0..1:c;%% Whether we construct the roadvarint:cost_road=286*c+1000000*(1-c);varint:cost_final=min([cost_road,cost1,cost2]);

Note the big coefficient in the definition of cost_road. It can lead to numerical issues and a wrong answer: when the solver’s integrality tolerance is 1e-6, it can assume c=0.999999 as equivalent to c=1 leading to cost_road=287 after rounding.

A better solution, given reasonable bounds on cost1 and cost2, is to replace the definition as follows:

int:cost_others_ub=1+2*ub_array([cost1,cost2]);%% Multiply by 2 for a stronger LP relaxationvarint:cost_road=286*c+cost_others_ub*(1-c);

The following command-line options affect the backend or invoke extra functionality. Note that some of them have default values which may be different from the backend’s ones.
For example, tolerances have been tightened to enable more precise solving with integer variables and objective. This slightly deteriorates performance on average, so when your model has moderate constant and bound magnitudes, you may want to pass negative values to use solver’s defaults.

Optionally use the SEC cuts for the circuit global constraint.
Currently only Gurobi and IBM ILOG CPLEX (2019/03).
If compiling from source, this needs boost and cmake flag -DCOMPILE_BOOST_MINCUT=ON
(or #define it in lib/algorithms/min_cut.cpp).
Values of nSECcuts: 0,1: use MTZ formulation; 1,2: pass on circuit constraints
to the SEC cut generator, so 1 would use both.

Some constraints in the model can be declared as user and/or lazy cuts and they will be added to the corresponding pools
for the solvers supporting them. For that, apply annotations ::MIP_cut and/or ::MIP_lazy after a constraint.
For Gurobi and IBM ILOG CPLEX, see share/minizinc/linear/options.mzn for their exact meaning.

MiniZinc has experimental support for non-linear solvers that conform to the AMPL NL standard. There are a number of open-source solvers, such as Ipopt, Bonmin and Couenne, that can be interfaced to MiniZinc in this way.

You can download binaries of these solvers from AMPL (https://ampl.com/products/solvers/open-source/). In order to use them with MiniZinc, you need to create a solver configuration file. Future version of MiniZinc will make this easier, but for now you can follow these steps:

Download the solver binary. For this example, we assume you chose the Couenne solver, which supports non-linear, non-convex, mixed discrete and continuous problems.

Create a solver configuration file called couenne.msc in the share/minizinc/solvers directory of your MiniZinc installation, with the following contents:

You can adapt the version field if you downloaded a different version (it’s only used for displaying).

Run minizinc --solvers. The Couenne solver should appear in the list of solvers now.

Run minizinc --solver couenne model.mzn on some MiniZinc model, or use Couenne from the MiniZinc IDE.

The AMPL NL support is currently experimental, and your MiniZinc model is translated to NL without regard for the capabilities of the target solver. For example, Ipopt only supports continuous variables, so translating a model with integer variables will result in a solver-level error message. There is currently no support for translating Boolean variables and constraints into 0/1 integer variables (as required by e.g. Couenne). You can experiment with the standard linearisation library, using the -Glinear flag. However, this will linearise all integer constraints, even the ones that solvers like Couenne may support natively (it does allow you to use non-linear constraints on float variables, though). We will ship dedicated solver libraries for some NL solvers with future versions of MiniZinc.