unstable type change

[haavardhvarnes]

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]

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]

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]

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

[haavardhvarnes]

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]

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

[haavardhvarnes]

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]

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: https://github.com/oxfordcontrol/Clarabel.jl/issues/105

[goulart-paul]

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