Fix() variables not working with COSMO or Clarabel

Specific Domains Optimization (Mathematical)
1

I discoverd the issue trying a non-linear problem, but I can reproduce it with a simple linear example.

using JuMP, Tulip, COSMO, Clarabel
# const MT = Float64
const MT = Float32

# enough curvature to be interesting
x = collect(range( zero(MT), convert(MT, pi * 3/8), length = 11 ));
y = tan.(x);
typeof(y), length(y)

# m = GenericModel{MT}(Tulip.Optimizer{MT})
# m = GenericModel{MT}(COSMO.Optimizer{MT})
m = GenericModel{MT}(Clarabel.Optimizer{MT})

# tan should be rational, this is a MWE
nn = 3
@variable(m, p[1:nn+1] )
# its an odd function
fix(p[1], zero(MT))

# objective
@variable(m, t >= zero(MT))
@objective(m, Min, t)

# simple absolute error
for i = 1:length(x)
    if (iszero(y[i]))
        # must be zero at a root
        @constraint(m, 
            sum(p[j] * x[i]^(j-1) for j in 1:nn+1) == zero(MT) );
    else
        @constraint(m, 
            ( sum(p[j] * x[i]^(j-1) for j in 1:nn+1) - y[i] ) <= t );
        @constraint(m, 
            -t  <= (sum(p[j] * x[i]^(j-1) for j in 1:nn+1) - y[i] ) );
    end
end

set_silent(m)
optimize!(m)

println( "status = ", termination_status(m),
        ", objective = ", objective_value(m))

ncoeffs = value.(p)

The results I get are

# Float32:
#    Tulip : 0.0,          1.5191559, -1.9207443, 1.9895213
#    Cosmo : 3.8421135f-8, 1.519427, -1.9212689, 1.9897709
# Clarabel : MethodError: no method matching scaled_unit_shift! ...
#      
# Float64:
#    Tulip : .0,                     1.519270330430467, -1.920917372573802, 1.9895816924534657
#    Cosmo : -7.603705038638703e-8,  1.5194154485424174, -1.921242527624281,  1.9897561618609008
# Clarabel : 1.2425935174645088e-14, 1.519270333022516, -1.9209173782400322, 1.9895816954288656

Clarabel is failing for Float32, but both COSMO and Clarabel seem to have trouble fixing the constant term in 32 or 64 bit.

1 Like
2

I confirm that this is a bug in Clarabel at least (didn’t try COSMO yet). I will file a bug report on github and we can provide a fix.

I think it is just an internal type matching issue, so should be easy to fix.

Edit: Fixed here: Fix type errors for #135 by goulart-paul · Pull Request #136 · oxfordcontrol/Clarabel.jl · GitHub

We will include this in the next minor release.

2 Likes