Creating efficient MOI wrapper for different cones and ordering them by types

Specific Domains Optimization (Mathematical)
1

I’m considering to create a MOI wrapper for CuClarabel, where users can input different types of cones in arbitrary order while the MOI wrapper is able to order them in a predefined order and then pass it to CuClarabel. The current implementation is quite inefficient as I have to loop over different types, see here. Is there any efficient way to do it?

2

Yes, this is one common problem with the design of MOI.

The quick answer is that there is no efficient type stable way.

A better answer is that you can use a function barrier, so that iterating over the constraint types is unstable, but iterating over the list of constraints within a particular constraint type is stable.

See, e.g.,

3

Thanks! I tried to modified it accoring to it but found another issue for the current MOI wrapper of Clarabel. Even for the following simple example,

using JuMP
using Clarabel  

model = Model(Clarabel.Optimizer)
@variable(model, x[1:3])

@constraint(model, x[1:2] >= 0)
@constraint(model, sum(x) == 3.0)

@objective(model, Min, x[1])

optimize!(model)

After creating an CachingOptimizer object and calling optimize!(model), I found this function is executed twice, where it went into the default copy_to!() at here and then executed copy_to!() defined in Clarabel.

The issue may come from the initialization for the CachingOptimizer.optimizer for Clarabel is of the type MOIB.LazyBridgeOptimizer{MOIU.CachingOptimizer{Clarabel.MOIwrapper.Optimizer{Float64}, MOIU.UniversalFallback{MOIU.Model{Float64}}}} while other solvers like HiGHS creating MOIB.LazyBridgeOptimizer{HiGHS.Optimizer}. It seems that there is one redudant layer MOIU.CachingOptimizer making an additional calling. Why don’t Clarabel creates an object like MOIB.LazyBridgeOptimizer{Clarabel.MOIwrapper.Optimizer}?

4

Something similar (I think) already happens elsewhere in the solver, specifically here.

The idea is to write a macro that gets all concrete subtypes of some abstract type, then unroll a big if/else switchyard calling appropriate functions on those types. That turned out to be quite a bit faster than relying on dynamic dispatch.