oxfordcontrol
ClarabelRs with `faer` result in `NumericalError`. Saving to `json` and reloading fixes issue?
Hi there,
I am slightly puzzled by this. I am reading a model from a cbf using JuMP and setting the direct method to :faer. Unfortunately something happens and the solver bails with a NumericalError.
using JuMP, ClarabelRs
path_to_file = joinpath(@__DIR__,path_to_files, file_name)
model_faer = read_from_file(path_to_file)
set_optimizer(model_faer, ClarabelRs.Optimizer)
set_attribute(model_faer, "direct_solve_method", :faer)
optimize!(model_faer)
-------------------------------------------------------------
Clarabel.rs v0.9.0 - Clever Acronym
(c) Paul Goulart
University of Oxford, 2022
-------------------------------------------------------------
problem:
variables = 86778
constraints = 112351
nnz(P) = 0
nnz(A) = 580925
cones (total) = 8251
: Zero = 1, numel = 58738
: Nonnegative = 2, numel = (1,4124)
: PSDTriangle = 8248, numel = (6,6,6,6,...,6)
settings:
linear algebra: direct / faer, precision: 64 bit
max iter = 200, time limit = Inf, max step = 0.990
tol_feas = 1.0e-8, tol_gap_abs = 1.0e-8, tol_gap_rel = 1.0e-8,
static reg : on, ϵ1 = 1.0e-8, ϵ2 = 4.9e-32
dynamic reg: on, ϵ = 1.0e-13, δ = 2.0e-7
iter refine: on, reltol = 1.0e-13, abstol = 1.0e-12,
max iter = 10, stop ratio = 5.0
equilibrate: on, min_scale = 1.0e-4, max_scale = 1.0e4
max iter = 10
iter pcost dcost gap pres dres k/t μ step
---------------------------------------------------------------------------------------------
0 +9.2749e-01 +9.2749e-01 1.99e-13 1.34e-01 2.21e-02 1.00e+00 5.72e+01 ------
1 -2.6265e+01 -2.0492e+01 2.82e-01 6.95e-02 1.10e-02 6.28e+00 3.43e+01 5.22e-01
2 -5.2928e+04 -5.2918e+04 1.87e-04 1.62e-02 3.85e-03 1.05e+01 3.42e+01 5.27e-02
3 -2.0302e+05 -2.0300e+05 9.90e-05 5.32e-03 1.29e-03 2.09e+01 2.91e+01 2.45e-01
4 -3.0882e+05 -3.0879e+05 9.61e-05 3.69e-03 8.97e-04 3.05e+01 2.55e+01 2.20e-01
5 -5.1792e+05 -5.1788e+05 8.41e-05 2.22e-03 5.39e-04 4.44e+01 1.98e+01 3.30e-01
6 -7.7519e+05 -7.7514e+05 7.13e-05 1.37e-03 3.32e-04 5.60e+01 1.45e+01 3.72e-01
7 -8.6242e+05 -8.6237e+05 6.44e-05 1.10e-03 2.66e-04 5.62e+01 1.21e+01 2.38e-01
8 -8.7572e+05 -8.7566e+05 5.90e-05 9.33e-04 2.26e-04 5.23e+01 1.03e+01 2.35e-01
9 -8.7381e+05 -8.7377e+05 5.12e-05 7.88e-04 1.91e-04 4.52e+01 8.64e+00 2.13e-01
10 -8.0331e+05 -8.0328e+05 3.94e-05 5.53e-04 1.34e-04 3.20e+01 5.77e+00 4.97e-01
11 -7.6529e+05 -7.6526e+05 3.36e-05 4.20e-04 1.01e-04 2.59e+01 4.25e+00 4.44e-01
12 -7.4962e+05 -7.4961e+05 2.49e-05 2.95e-04 7.11e-05 1.88e+01 2.94e+00 4.23e-01
13 -7.5090e+05 -7.5089e+05 2.17e-05 2.05e-04 4.95e-05 1.64e+01 2.03e+00 6.92e-01
14 -7.4220e+05 -7.4219e+05 1.34e-05 1.17e-04 2.83e-05 9.98e+00 1.15e+00 6.79e-01
15 -7.3116e+05 -7.3116e+05 7.48e-06 6.46e-05 1.55e-05 5.50e+00 6.25e-01 5.42e-01
16 -7.2435e+05 -7.2434e+05 3.51e-06 2.90e-05 6.97e-06 2.55e+00 2.78e-01 7.46e-01
17 -7.2435e+05 -7.2434e+05 3.51e-06 2.90e-05 6.97e-06 2.55e+00 2.78e-01 0.00e+00
---------------------------------------------------------------------------------------------
Terminated with status = NumericalError
solve time = 4.263004331s
What I find puzzling is that if I save the model to a json file and then load the model from said json file it seems as no NumericalError is encountered even though the initial iterations are exactly the same?
json_file = joinpath(@__DIR__,path_to_files, file_name)[1:end-4] * ".json"
ClarabelRs.write_to_file(unsafe_backend(model_faer).solver,json_file)
json_solver = ClarabelRs.read_from_file(json_file)
ClarabelRs.solve!(json_solver)
-------------------------------------------------------------
Clarabel.rs v0.9.0 - Clever Acronym
(c) Paul Goulart
University of Oxford, 2022
-------------------------------------------------------------
problem:
variables = 86778
constraints = 112351
nnz(P) = 0
nnz(A) = 580925
cones (total) = 8251
: Zero = 1, numel = 58738
: Nonnegative = 2, numel = (1,4124)
: PSDTriangle = 8248, numel = (6,6,6,6,...,6)
settings:
linear algebra: direct / faer, precision: 64 bit
max iter = 200, time limit = Inf, max step = 0.990
tol_feas = 1.0e-8, tol_gap_abs = 1.0e-8, tol_gap_rel = 1.0e-8,
static reg : on, ϵ1 = 1.0e-8, ϵ2 = 4.9e-32
dynamic reg: on, ϵ = 1.0e-13, δ = 2.0e-7
iter refine: on, reltol = 1.0e-13, abstol = 1.0e-12,
max iter = 10, stop ratio = 5.0
equilibrate: on, min_scale = 1.0e-4, max_scale = 1.0e4
max iter = 10
iter pcost dcost gap pres dres k/t μ step
---------------------------------------------------------------------------------------------
0 +9.2749e-01 +9.2749e-01 2.02e-13 1.34e-01 2.21e-02 1.00e+00 5.72e+01 ------
1 -2.6265e+01 -2.0492e+01 2.82e-01 6.95e-02 1.10e-02 6.28e+00 3.43e+01 5.22e-01
2 -5.2928e+04 -5.2918e+04 1.87e-04 1.62e-02 3.85e-03 1.05e+01 3.42e+01 5.27e-02
3 -2.0302e+05 -2.0300e+05 9.90e-05 5.32e-03 1.29e-03 2.09e+01 2.91e+01 2.45e-01
4 -3.0882e+05 -3.0879e+05 9.61e-05 3.69e-03 8.97e-04 3.05e+01 2.55e+01 2.20e-01
5 -5.1792e+05 -5.1788e+05 8.41e-05 2.22e-03 5.39e-04 4.44e+01 1.98e+01 3.30e-01
6 -7.7519e+05 -7.7514e+05 7.13e-05 1.37e-03 3.32e-04 5.60e+01 1.45e+01 3.72e-01
7 -8.6242e+05 -8.6237e+05 6.44e-05 1.10e-03 2.66e-04 5.62e+01 1.21e+01 2.38e-01
8 -8.7572e+05 -8.7566e+05 5.90e-05 9.33e-04 2.26e-04 5.23e+01 1.03e+01 2.35e-01
9 -8.7381e+05 -8.7377e+05 5.12e-05 7.88e-04 1.91e-04 4.52e+01 8.64e+00 2.13e-01
10 -8.0331e+05 -8.0328e+05 3.94e-05 5.53e-04 1.34e-04 3.20e+01 5.77e+00 4.97e-01
11 -7.6529e+05 -7.6526e+05 3.36e-05 4.20e-04 1.01e-04 2.59e+01 4.25e+00 4.44e-01
12 -7.4962e+05 -7.4961e+05 2.49e-05 2.95e-04 7.11e-05 1.88e+01 2.94e+00 4.23e-01
13 -7.5090e+05 -7.5089e+05 2.17e-05 2.05e-04 4.95e-05 1.64e+01 2.03e+00 6.92e-01
14 -7.4220e+05 -7.4219e+05 1.34e-05 1.17e-04 2.83e-05 9.98e+00 1.15e+00 6.79e-01
15 -7.3116e+05 -7.3116e+05 7.48e-06 6.46e-05 1.55e-05 5.50e+00 6.25e-01 5.42e-01
16 -7.2435e+05 -7.2434e+05 3.51e-06 2.90e-05 6.97e-06 2.55e+00 2.78e-01 7.46e-01
17 -7.1920e+05 -7.1920e+05 1.74e-06 1.42e-05 3.41e-06 1.26e+00 1.35e-01 6.34e-01
18 -7.1909e+05 -7.1909e+05 1.63e-06 1.33e-05 3.19e-06 1.18e+00 1.26e-01 2.01e-01
19 -7.1601e+05 -7.1600e+05 7.13e-07 5.74e-06 1.38e-06 5.14e-01 5.44e-02 7.54e-01
20 -7.1424e+05 -7.1424e+05 2.61e-07 2.09e-06 5.01e-07 1.87e-01 1.97e-02 8.37e-01
21 -7.1373e+05 -7.1373e+05 1.37e-07 1.10e-06 2.64e-07 9.86e-02 1.04e-02 8.37e-01
22 -7.1341e+05 -7.1341e+05 6.61e-08 5.29e-07 1.27e-07 4.74e-02 4.98e-03 6.06e-01
23 -7.1320e+05 -7.1320e+05 2.16e-08 1.73e-07 4.14e-08 1.55e-02 1.62e-03 8.38e-01
24 -7.1315e+05 -7.1315e+05 9.32e-09 7.45e-08 1.79e-08 6.69e-03 7.01e-04 9.90e-01
25 -7.1312e+05 -7.1312e+05 3.67e-09 2.93e-08 7.04e-09 2.63e-03 2.76e-04 8.70e-01
26 -7.1311e+05 -7.1311e+05 1.52e-09 1.22e-08 2.92e-09 1.09e-03 1.14e-04 7.66e-01
27 -7.1311e+05 -7.1311e+05 8.49e-10 6.79e-09 1.63e-09 6.09e-04 6.37e-05 7.22e-01
---------------------------------------------------------------------------------------------
Terminated with status = Solved
solve time = 6.56012246s
I have observed this as well and don't have a convincing explanation. We do not store the data as provided by the user, but only the data in its post-equilibrated form. We then undo that equilibration when saving to json, so in principle it is possible for the problem data to be perturbed by that process just enough to produce a different result. Does the same thing happen if you save the problem with equilibration disabled, and then import with it enabled again (this would have to be done manually for now I guess). If that still produces weird behaviour then maybe something else is going on.
I just tried to follow your suggestion. When equilibration is disabled the problem is solved directly on the first go, i.e. no NumericalError is encountered. So your hunch of it being related to the equilibration must be correct.
This has possibly been fixed (or at least improved) by enabling the float_roundtrip feature in the json packages. Part of the issue you saw may have been caused by very small roundoff errors incurred when passing to/from the JSON files.