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 non-linear 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
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 finite-precision
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 re-evaluated
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 tolerance-unaware checker.
By default, “idealistic” check is performed for objective values only,
see example below. To enable it for constraints, use
option chk:mode.
“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=1e-06, :feastolrel=1e-06, :inttol=1e-05,
: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
right-hand side is of moderate magnitude (in this case zero,
that’s why the relative violation is missing).
“Idealistic” solution check
In this mode, non-linear 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=1e-06, :feastolrel=1e-06, :inttol=1e-05,
: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/solution-check.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=1e-06, :feastolrel=1e-06, :inttol=1e-05,
: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/solution-check.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=1e-06, :feastolrel=1e-06, :inttol=1e-05,
: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/solution-check.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.