unstable type change #149

haavardhvarnes · 2023-11-05T20:51:43Z

Trying multiple types on example in documentation seems to give an error when changing to Float32 ( Float64 and BigFloat works fine).

`using Clarabel, SparseArrays, LinearAlgebra

P = sparse([3.0 1 -1; 0 4 2; 0 0 5])
q = [1, 2, -3.0]

equality constraint

Aeq = [1.0 1.0 -1.0]
beq = [1.0]

inequality constraint

Aineq = [0.0 1.0 0.0
0.0 0.0 1.0]
bineq = [2.0, 2.0]

SOC constraint

Asoc = -I(3) * 1.0
bsoc = [0.0, 0.0, 0.0]

Clarabel.jl constraint data

A_ = sparse([Aeq; Aineq; Asoc])
b_ = [beq; bineq; bsoc]
A = sparse([Aeq; Aineq])
b = [beq; bineq]

Clarabel.jl cone specification

#cones = [Clarabel.ZeroConeT(1), Clarabel.NonnegativeConeT(2), Clarabel.SecondOrderConeT(3)]
cones = [Clarabel.ZeroConeT(1), Clarabel.NonnegativeConeT(2)]

const T = Float64

settings = Clarabel.Settings{T}()

settings64 = Clarabel.Settings{Float64}(
verbose=true,
direct_solve_method=:qdldl)
solver64 = Clarabel.Solver{Float64}()
Clarabel.setup!(solver64, P, q, A, b, cones, settings64)
solution64 = Clarabel.solve!(solver64)

settings32 = Clarabel.Settings{Float32}(
verbose=true,
direct_solve_method=:qdldl)
solver32 = Clarabel.Solver{Float32}()
Clarabel.setup!(solver32, Float32.(P), Float32.(q), Float32.(A), Float32.(b), cones, settings32)
solution32 = Clarabel.solve!(solver32)
`

Hope I have done some elementary error.

goulart-paul · 2023-11-05T22:12:01Z

Your example above works fine for me, in the sense that I don't get a type error. The solver does not converge to full accuracy though because the default tolerances are probably too tight for a Float32 problem.

What error do you get, and what version are you using?

haavardhvarnes · 2023-11-07T20:19:11Z

Sorry late reply, this is the error message:
`julia> solution32 = Clarabel.solve!(solver32)
LLVM ERROR: Instruction Combining seems stuck in an infinite loop after 1000 iterations.

[48519] signal (6): Abort trap: 6
in expression starting at REPL[26]:1
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 53219812 (Pool: 53130412; Big: 89400); GC: 16
zsh: abort /Applications/Julia-1.10.app/Contents/Resources/julia/bin/julia

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions... 4 completed.

[Process completed]`

Versioninfo:
julia> versioninfo()
Julia Version 1.10.0-beta3
Commit 404750f8586 (2023-10-03 12:53 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: macOS (arm64-apple-darwin22.4.0)
CPU: 8 × Apple M1
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 5 on 4 virtual cores
Environment:
JULIA_NUM_THREADS = 4

julia> using Clarabel

(@v1.10) pkg> st Clarabel
Status ~/.julia/environments/v1.10/Project.toml
[61c947e1] Clarabel v0.6.0

(@v1.10) pkg>

goulart-paul · 2023-11-07T20:21:53Z

That seems weird - does that happen on the current stable version Julia (1.9.3)?

haavardhvarnes · 2023-11-07T20:31:02Z

Still error though no crash of Julia:

`
julia> solution32 = Clarabel.solve!(solver32)

       Clarabel.jl v0.5.1  -  Clever Acronym              
               (c) Paul Goulart                          
            University of Oxford, 2022

problem:
variables = 3
constraints = 3
nnz(P) = 6
nnz(A) = 5
cones (total) = 2
: Zero = 1, numel = 1
: Nonnegative = 1, numel = 2

settings:
linear algebra: direct / qdldl, precision: Float32
max iter = 200, time limit = Inf, max step = 0.990
tol_feas = 1.0e-08, tol_gap_abs = 1.0e-08, tol_gap_rel = 1.0e-08,
static reg : on, ϵ1 = 1.0e-08, ϵ2 = 4.9e-32
dynamic reg: on, ϵ = 1.0e-13, δ = 2.0e-07
iter refine: on, reltol = 1.0e-13, abstol = 1.0e-12,
max iter = 10, stop ratio = 5.0
equilibrate: on, min_scale = 1.0e-04, max_scale = 1.0e+04
max iter = 10

iter pcost dcost gap pres dres k/t μ step

ERROR: MethodError: no method matching scaled_unit_shift!(::Clarabel.CompositeCone{Float32}, ::Clarabel.ConicVector{Float32}, ::Float64, ::Clarabel.PrimalOrDualCone)

Closest candidates are:
scaled_unit_shift!(::Clarabel.CompositeCone{T}, ::Clarabel.ConicVector{T}, ::T, ::Clarabel.PrimalOrDualCone) where T
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/cones/coneops_compositecone.jl:97
scaled_unit_shift!(::Clarabel.ZeroCone{T}, ::AbstractVector{T}, ::T, ::Clarabel.PrimalOrDualCone) where T
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/cones/coneops_zerocone.jl:42
scaled_unit_shift!(::Clarabel.NonnegativeCone{T}, ::AbstractVector{T}, ::T, ::Clarabel.PrimalOrDualCone) where T
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/cones/coneops_nncone.jl:42
...

Stacktrace:
[1] _shift_to_cone_interior!(z::Clarabel.ConicVector{Float32}, cones::Clarabel.CompositeCone{Float32}, pd::Clarabel.PrimalOrDualCone)
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/variables.jl:193
[2] variables_symmetric_initialization!
@ ~/.julia/packages/Clarabel/AwMRn/src/variables.jl:173 [inlined]
[3] solver_default_start!(s::Clarabel.Solver{Float32})
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/solver.jl:360
[4] macro expansion
@ ~/.julia/packages/TimerOutputs/RsWnF/src/TimerOutput.jl:237 [inlined]
[5] macro expansion
@ ~/.julia/packages/Clarabel/AwMRn/src/solver.jl:188 [inlined]
[6] macro expansion
@ ~/.julia/packages/TimerOutputs/RsWnF/src/TimerOutput.jl:237 [inlined]
[7] solve!(s::Clarabel.Solver{Float32})
@ Clarabel ~/.julia/packages/Clarabel/AwMRn/src/solver.jl:185
[8] top-level scope
@ REPL[26]:1
`

goulart-paul · 2023-11-07T20:34:09Z

Current version of the Clarabel package is 0.6.0 - perhaps try Pkg.update("Clarabel") ?

haavardhvarnes · 2023-11-07T20:59:56Z

Noticed as well, though needed to upgrade a lot of packages. Now it provided a solution though status is ALMOST_SOLVED but anyway seems to give correct answer 👍

A bit strange that v1.10-beta3 is crashing and it seems because of Julia itself. Thanks anyway for your patience and quick replies!

julia> solution32 = Clarabel.solve!(solver32)

       Clarabel.jl v0.6.0  -  Clever Acronym              
               (c) Paul Goulart                          
            University of Oxford, 2022

problem:
variables = 3
constraints = 3
nnz(P) = 6
nnz(A) = 5
cones (total) = 2
: Zero = 1, numel = 1
: Nonnegative = 1, numel = 2

settings:
linear algebra: direct / qdldl, precision: Float32
max iter = 200, time limit = Inf, max step = 0.990
tol_feas = 1.0e-08, tol_gap_abs = 1.0e-08, tol_gap_rel = 1.0e-08,
static reg : on, ϵ1 = 1.0e-08, ϵ2 = 4.9e-32
dynamic reg: on, ϵ = 1.0e-13, δ = 2.0e-07
iter refine: on, reltol = 1.0e-13, abstol = 1.0e-12,
max iter = 10, stop ratio = 5.0
equilibrate: on, min_scale = 1.0e-04, max_scale = 1.0e+04
max iter = 10

iter pcost dcost gap pres dres k/t μ step

0 6.7343e+00 -1.5943e+01 3.37e+00 0.00e+00 8.40e-01 1.00e+00 1.75e+00 ------
1 5.6728e+00 -2.0018e+01 4.53e+00 1.40e-07 4.41e-02 3.18e+00 2.42e-01 9.90e-01
2 2.5278e+00 -1.1634e+00 3.17e+00 3.46e-08 6.93e-04 5.02e-01 2.73e-02 9.90e-01
3 2.3971e+00 2.1739e+00 1.03e-01 4.92e-08 7.50e-06 3.12e-02 1.50e-03 9.90e-01
4 2.3966e+00 2.3934e+00 1.31e-03 4.95e-08 6.20e-08 4.41e-04 2.10e-05 9.90e-01
5 2.3966e+00 2.3965e+00 1.33e-05 7.43e-08 2.78e-08 4.41e-06 2.10e-07 9.90e-01
6 2.3966e+00 2.3966e+00 1.99e-07 4.76e-08 2.94e-08 4.34e-08 2.14e-09 9.81e-01
7 2.3966e+00 2.3966e+00 9.95e-08 4.01e-08 3.23e-08 2.61e-09 1.06e-10 9.90e-01
8 2.3966e+00 2.3966e+00 2.98e-07 2.76e-08 3.14e-08 3.58e-09 1.25e-09 9.90e-01
9 2.3966e+00 2.3966e+00 0.00e+00 2.59e-08 7.92e-08 1.57e-09 1.56e-10 9.90e-01
10 2.3966e+00 2.3966e+00 9.95e-08 2.58e-08 4.08e-08 7.55e-10 2.46e-10 9.90e-01
11 2.3966e+00 2.3966e+00 1.99e-07 8.81e-08 1.09e-07 1.78e-09 3.51e-11 9.90e-01
12 2.3966e+00 2.3966e+00 0.00e+00 1.05e-08 3.71e-08 2.63e-10 2.57e-12 9.90e-01
13 2.3966e+00 2.3966e+00 9.95e-08 3.21e-08 4.26e-08 1.13e-10 2.99e-12 9.90e-01

Terminated with status = solved (reduced accuracy)
solve time = 1.09s

Clarabel - Results
Status: ALMOST_SOLVED
Iterations: 13
Objective: 2.397
Solve time: 1.09s

julia>

goulart-paul · 2023-11-07T21:03:02Z

I would guess that the reason you are getting "almost solved" is that the values in the default settings are really chosen with Float64 in mind. It is likely that the tolerances are way too tight for Float32 data.

See relevant comment at the end of this issue: #105

goulart-paul · 2024-05-21T14:05:12Z

I don't know that there is anything to do here, so will close.

goulart-paul closed this as completed May 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unstable type change #149

unstable type change #149

haavardhvarnes commented Nov 5, 2023

goulart-paul commented Nov 5, 2023

haavardhvarnes commented Nov 7, 2023

goulart-paul commented Nov 7, 2023

haavardhvarnes commented Nov 7, 2023

goulart-paul commented Nov 7, 2023

haavardhvarnes commented Nov 7, 2023

goulart-paul commented Nov 7, 2023

goulart-paul commented May 21, 2024

unstable type change #149

unstable type change #149

Comments

haavardhvarnes commented Nov 5, 2023

equality constraint

inequality constraint

SOC constraint

Clarabel.jl constraint data

Clarabel.jl cone specification

const T = Float64

settings = Clarabel.Settings{T}()

goulart-paul commented Nov 5, 2023

haavardhvarnes commented Nov 7, 2023

goulart-paul commented Nov 7, 2023

haavardhvarnes commented Nov 7, 2023

` julia> solution32 = Clarabel.solve!(solver32)

iter pcost dcost gap pres dres k/t μ step

goulart-paul commented Nov 7, 2023

haavardhvarnes commented Nov 7, 2023

julia> solution32 = Clarabel.solve!(solver32)

iter pcost dcost gap pres dres k/t μ step

goulart-paul commented Nov 7, 2023

goulart-paul commented May 21, 2024

`
julia> solution32 = Clarabel.solve!(solver32)