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?
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.,
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}
?