Tools & details¶
This section highlight some tools aiding modeling and solving.
Supported constraints¶
To find out which constraints are natively supported by the solver, or, more generally, understood by MP, there are two ways.
Method 1: acceptance options¶
List the solver’s natively supported constraints,
by running the solver executable with the =acc
commandline switch
which lists all solver options starting with the acc:
prefix:
gurobi =acc
Alternatively, the full option list for each solver is published at AMPL Development.
Method 2: full constraint list¶
List all constraints known by the MP model converter, including some
internal ones, by running the solver executable with the c
commandline switch. Here is a beautified summary of the resulting
(rather technical) output for a generic solver:
ID 
Full name 


1 
abs 
AbsConstraint 
2 
acos 
AcosConstraint 
3 
acosh 
AcoshConstraint 
4 
alldiff 
AllDiffConstraint 
5 
and 
AndConstraint 
6 
asin 
AsinConstraint 
7 
asinh 
AsinhConstraint 
8 
atan 
AtanConstraint 
9 
atanh 
AtanhConstraint 
10 
compl 
ComplementarityLinear 
11 
complquad 
ComplementarityQuadratic 
12 
condlin(lt/le/eq/ge/gt) 
Conditional linear constraint 
13 
condquad(lt/le/eq/ge/gt) 
Conditional quadratic constraint 
14 
cos 
CosConstraint 
15 
cosh 
CoshConstraint 
16 
count 
CountConstraint 
17 
div 
DivConstraint 
18 
expa 
ExpAConstraint 
19 
exp 
ExpConstraint 
20 
expcone 
ExponentialConeConstraint 
21 
geomcone 
GeometricConeConstraint 
22 
ifthen 
IfThenConstraint 
23 
impl 
ImplicationConstraint 
24 
ind(le/eq/ge) 
Linear indicator constraint 
25 
indquad(le/eq/ge) 
Quadratic indicator constraint 
26 
lin(le/eq/ge) 
Linear constraint 
27 
linrange 
Linear range constraint 
28 
linfunccon 
LinearFunctionalConstraint 
29 
loga 
LogAConstraint 
30 
log 
LogConstraint 
31 
max 
MaxConstraint 
32 
min 
MinConstraint 
33 
not 
NotConstraint 
34 
numberofconst 
NumberofConstConstraint 
35 
numberofvar 
NumberofVarConstraint 
36 
or 
OrConstraint 
37 
pl 
PLConstraint 
38 
pow 
PowConstraint 
39 
powercone 
PowerConeConstraint 
40 
quad(le/eq/ge) 
Quadratic constraint 
41 
quadrange 
Quadratic range constraint 
42 
quadcone 
QuadraticConeConstraint 
43 
quadfunccon 
QuadraticFunctionalConstraint 
44 
rotatedquadcone 
RotatedQuadraticConeConstraint 
45 
sos1 
SOS1Constraint 
46 
sos2 
SOS2Constraint 
47 
sin 
SinConstraint 
48 
sinh 
SinhConstraint 
49 
tan 
TanConstraint 
50 
tanh 
TanhConstraint 
Explore the reformulations¶
To explore the reformulations performed on your model, there are the following ways.
Explore the final model¶
To explore the model received by the solver, export the model in one of the solver’s general formats:
ampl: option mosek_auxfiles rc; ## To use var/con names
ampl: option mosek_options 'writeprob=/tmp/ell.jtask'; solve;
Some solvers can export their presolved model:
option gurobi_options 'outlev=1 writepresolved=disj_pre.lp';
Reformulation graph¶
The flattening and reformulation graph can be exported
by the cvt:writegraph
option (WIP).
At the moment only arcs are exported. Terminal nodes (variables, constraints,
objectives) can be seen in the NL model (ampl: expand
) and the
final flat model (gurobi: option tech:writeprob
).
Automatic solution check¶
Solutions obtained from the solver are automatically checked
for correctness with given tolerances
(see Solver options sol:chk:...
.)
There are two checking modes: “realistic” and “idealistic”. For linear and quadratic models they are equivalent. Differences can arise for models with other nonlinear expressions.
In “realistic” mode, any expressions computed by the solver and reported via an auxiliary variable, are trusted with a tolerance. In “idealistic” mode, all expression trees are recomputed.
Motivation¶
Consider the disjunction constraint
C: y<=6 or z>=10;
With y=6.0000000001
and z=9.9999999999
, and assuming the solver’s
feasibility tolerance is at a typical value (such as \(10^{6}\)),
most Mathematical Programming solvers consider the disjunction satisfied.
And, from a practical viewpoint, it is (given finiteprecision
computations).
Our “realistic” checking mode does exactly this: it trusts the solver results up to a tolerance.
In contrast, AMPL reports the constraint violated:
ampl: let y:=6.0000000001;
ampl: let z:=9.9999999999;
ampl: display C.val;
C.val = 0
That is, when expressions y<=6
and z>=10
are reevaluated
and their results substituted into C
, C
holds false.
The role of the “idealistic” checking mode is to warn the user about the fact, that even if the solver has a correct solution up to its tolerances (which is examined by the “realistic” mode), it can be wrong for a toleranceunaware checker.
By default, “idealistic” check is performed for objective values only,
see example below. To enable it for constraints, use
option chk:mode
.
Warnings format¶
Example¶
To explain the solution check warning format, let’s solve a relaxed version of the following model:
var x integer <= 0;
var y integer;
minimize TotalSum: x  2*y;
subject to C1: x + 21*y >= 2;
subject to C2: 3*x + 2*y <= 1;
subject to C3: 20*x + y <= 200;
Running Gurobi with option feasrelax 1
, we trick MP
(it does not know the effect of feasrelax
).
ampl: option solver gurobi;
ampl: option gurobi_options 'feasrelax 1';
ampl: option gurobi_auxfiles rc; ## To pass model names
ampl: solve;
Gurobi 10.0.2: alg:feasrelax = 1
Gurobi 10.0.2: optimal solution; feasrelax objective 160552
5 simplex iterations
1 branching nodes
absmipgap=2, relmipgap=1.2457e05
 WARNINGS 
WARNING: "Solution Check"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
 2 original variable(s) violate bounds,
up to 1E+05 (abs, item 'y'), up to 1E+00 (rel, item 'y')
Algebraic expression violations:
 1 linear constraint(s),
up to 2E+00 (abs, item 'C1'), up to 1E+00 (rel, item 'C1')
Objective value violations:
 1 objective value(s) violated,
up to 2E+05 (abs, item 'TotalSum')
WARNING: "Solution Check (Idealistic)"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
Objective value violations:
 1 objective value(s) violated,
up to 2E+05 (abs, item 'TotalSum')
AMPL may evaluate constraints/objectives differently
than the solver, see mp.ampl.com/solutioncheck.html.
After the solver log we see 2 warnings. The first is Solution Check
.
This reports the “realistic” violations. In square brackets we see
numeric solver options relevant for checking.
Then follows information on variable bound violations.
It includes the number of violations (2), maximal absolute violation
and variable name, as well as maximal relative violation.
Paragraph Algebraic expression violations
presents similar information,
for each expression type (see the full list). Paragraph
Objective value violations
does that for objectives.
The 2nd warning is Solution Check (Idealistic)
.
As the idealistic check is performed by default for objectives only,
this warning repeats the information about objective value violation.
Expression list¶
The full list of expressions which can be reported is given in section Full constraint list.
“Realistic” solution check¶
In this mode, variable values are taken as they were reported by the solver
(with possible modifications via options
sol:chk:round
and sol:chk:prec
.)
This check is enough for most practical situations, and its warnings mean
that the solver’s reported solution violates checking tolerances.
 WARNINGS 
WARNING: "Solution Check"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
Algebraic expression violations:
 1 quadratic constraint(s),
up to 1E+00 (item 'socp[13]')
In this example, realistic check reports a constraint violation of 1.0, which can mean a significant violation if the constraint’s righthand side is of moderate magnitude (in this case zero, that’s why the relative violation is missing).
“Idealistic” solution check¶
In this mode, nonlinear expressions are recomputed and compared to solver values. The recomputation is performed similar to how AMPL does it when asked to display objective value or constraint body / slack. Thus, “idealistic” violations mean objective and constraint expressions reported in AMPL may be different from the solver. While the most serious type of violations are the “realistic” ones, the “idealistic” mode warns about (significant) differences when expressions are recomputed from scratch. Consider the following example.
var x >=0, <=100;
maximize Total: if x<=5 and x>=5.00000000001 then 10;
Most solvers apply a constraint feasibility tolerance of the order \(10^{6}\).
ampl: option solver gurobi;
ampl: solve;
Gurobi 10.0.2: optimal solution; objective 10
0 simplex iterations
 WARNINGS 
WARNING: "Solution Check (Idealistic)"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
Objective value violations:
 1 objective value(s) violated,
up to 1E+01 (abs)
AMPL may evaluate constraints/objectives differently
than the solver, see mp.ampl.com/solutioncheck.html.
ampl: display x;
x = 5
We see that x=5
satisfies the if
with that tolerance.
Thus, our realistic check passes, but the idealistic check complains.
Indeed, if we ask AMPL to recompute the objective value:
ampl: display Total;
Total = 0
we see that AMPL does it “idealistically” (it does not know about solver tolerances, or whether the user has provided variable values manually.)
To see which expressions cause the violation,
use driver option chk:mode
:
ampl: option gurobi_options 'chk:mode=1023';
ampl: solve;
Gurobi 10.0.2: sol:chk:mode = 1023
Gurobi 10.0.2: optimal solution; objective 10
0 simplex iterations
 WARNINGS 
WARNING: "Solution Check (Idealistic)"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
Algebraic expression violations:
 1 constraint(s) of type ':ifthen',
up to 1E+01 (abs)
Logical expression violations:
 1 constraint(s) of type ':and'
Objective value violations:
 1 objective value(s) violated,
up to 1E+01 (abs)
AMPL may evaluate constraints/objectives differently
than the solver, see mp.ampl.com/solutioncheck.html.
Hint: to display AMPL model names,
set option (solver_)auxfiles rc;
as follows:
ampl: option gurobi_auxfiles rc;
ampl: solve;
Gurobi 10.0.2: sol:chk:mode = 1023
Gurobi 10.0.2: optimal solution; objective 10
0 simplex iterations
 WARNINGS 
WARNING: "Solution Check (Idealistic)"
[ sol:chk:feastol=1e06, :feastolrel=1e06, :inttol=1e05,
:round='', :prec='' ]
Algebraic expression violations:
 1 constraint(s) of type ':ifthen',
up to 1E+01 (abs, item 'Total_11_')
Logical expression violations:
 1 constraint(s) of type ':and',
(item 'Total_7_')
Objective value violations:
 1 objective value(s) violated,
up to 1E+01 (abs, item 'Total')
AMPL may evaluate constraints/objectives differently
than the solver, see mp.ampl.com/solutioncheck.html.
Remedies¶
For “realistic” solution violations, the reason is most probably Numerical accuracy.
For “idealistic” warnings, to make sure AMPL can access the true objective value, see a Colab example detailing a more common case and a remedy consisting of an explicit variable for the objective value.