set VariableName doesn't get called

[Wikunia]

I'm interested in getting the name of a variable by its variable index in my solver. See Wikunia/ConstraintSolver.jl#235

I've implemented

# Naming variables
MOI.supports(::Optimizer, ::MOI.VariableName, ::Type{MOI.VariableIndex}) = true

function MOI.get(model::Optimizer, ::MOI.VariableName, v::MOI.VariableIndex)
    return model.inner.search_space[v.value].name
end

function MOI.set(
    model::Optimizer, ::MOI.VariableName, v::MOI.VariableIndex, name::String
)
    println("Doesn't get called")
    model.inner.search_space[v.value].name = name
    return
end

and set MOIU.supports_default_copy_to(model::Optimizer, copy_names::Bool) = true

but a simple model like:

model = Model(optimizer_with_attributes(ConstraintSolver.Optimizer))
@variable(model, b, Bin)
@constraint(model, b <= 0.5)
optimize!(model)

doesn't call the set function and therefore using the get function returns the empty string.

The problem seems to be that copy_names is always set to false in various places like:

• https://github.com/jump-dev/MathOptInterface.jl/blob/master/src/Utilities/cachingoptimizer.jl#L171

Setting it to true there calls the set function just fine.

It mentions that it doesn't have to be set to true as it's handled by model_cache but I don't find any information about that.

Seems like the set function doesn't get called for GLPK either which seems to implement the same methods as Gurobi.

Thanks for any hints in what I'm doing wrong.

My understanding of the variants of different optimizers like CachingOptimizer, BridgeOptimizer etc is very limited so any explanation about it is also highly appreciated.

[blegat]

The names are indeed only stored in the cache, the optimizer don't need to support it.
If the optimizer is used in direct mode, there is not going to be any cache and the names will be set to the optimizer.
Why does the solver need the names ? Do the name affect how it is solved ?

[Wikunia]

The problem in my case is that I only support bounded integer variables and as far as I know there isn't anything I can do to tell that to MOI directly. Therefore I throw an error to the user when this happens which says something like:
"The variable with index 12 isn't bounded from both sides" which isn't really helpful as it's hard to find out what variable that is referring to.

[blegat]

Short-term hack

One solution would be to define IntegerInterval(lb, ub) and ask the user to do

@variable(model, x in IntegerInterval(lb, ub))

If the user creates variables differently, it won't be supported.
If this set is in MOI, JuMP could create a constrained variables in IntegerInterval in case both bounds are set and integer is true. Then we will also have IntegerLessThan, ...

Long-term solution

We should define MOI.Intersection and have JuMP call MOI.add_constrained_variable(model.moi_backend, MOI.Intersection(MOI.Integer(), MOI.Interval(lb, ub)) and in your solver you say MOI.supports_constrained_variable(::Optimizer, ::Type{MOI.Intersection{MOI.Integer, MOI.Interval{Float64}}}).
We hesitated in doing so because we didn't have any solver needing it but if you make a case, it might be worth it :)

[Wikunia]

I'm mostly wondering why the solver doesn't have access to the name of s variable 😂

Seems like the backend and frontend are ready but the link isn't get called but maybe I'm wrong.

I prefer to have the natural lb <= x <= ub way that I do now. I'm additionally wondering why it's not treated a an interval by default and instead is split up.

Currently it's not possible to define only integer variables as well, right (I mean even unbounded ones) ? Guess there is no solver for that 😃

[blegat]

I'm mostly wondering why the solver doesn't have access to the name of s variable

I know, I drifted a bit off topic but that's because it's expected that the solver does not get access to variable names (as copying the variables by default would be inefficient since it's never needed apart from your use case) so the issue is that the solver does not have a proper way to express that it only support bounded integer variables.

I'm additionally wondering why it's not treated a an interval by default and instead is split up.

Yes JuMP does not pass Integer constraints, I agree with you that it should. We could just add a branch here: https://github.com/jump-dev/JuMP.jl/blob/d2398ad1a5e90a3fda51274ccc3b48b88e1abbb9/src/variables.jl#L816

Currently it's not possible to define only integer variables as well, right (I mean even unbounded ones) ?

Normally, you could just not implement add_variable and add_variables and implement support_constrained_variables(::Optimizer, ::Type{MOI.Reals}) = false and add_constrained_variable(::Optimizer, ::MOI.Integer) and you will only get integer variables. If a variable is not integer, an error will be thrown when the model is loaded to the optimizer, the solver does not need to throw any error.

[Wikunia]

I know, I drifted a bit off topic but that's because it's expected that the solver does not get access to variable names (as copying the variables by default would be inefficient since it's never needed apart from your use case) so the issue is that the solver does not have a proper way to express that it only support bounded integer variables.

I was wondering whether I can actually set copy_names= true in my automatic_copy_to to have access. Didn't try it yet.

Yes JuMP does not pass Integer constraints, I agree with you that it should. We could just add a branch here: https://github.com/jump-dev/JuMP.jl/blob/d2398ad1a5e90a3fda51274ccc3b48b88e1abbb9/src/variables.jl#L816

You mean one where it has lower and upper bound and use the interval variable creation? Will this work with bridges such that solver which don't support interval use the different version?

Normally, you could just not implement add_variable and add_variables and implement support_constrained_variables(::Optimizer, ::Type{MOI.Reals}) = false and add_constrained_variable(::Optimizer, ::MOI.Integer) and you will only get integer variables. If a variable is not integer, an error will be thrown when the model is loaded to the optimizer, the solver does not need to throw any error.

Will have a look into it. Thought there was some kind of reason that I didn't. The current problem is that it's not possible to support == and not <= as an example as a slack variable would get created automatically to bridge it but that doesn't work when only integer variables are supported.
I implement == and <= but that's maybe something to be aware of.

[blegat]

You mean one where it has lower and upper bound and use the interval variable creation? Will this work with bridges such that solver which don't support interval use the different version?

Yes, something like

if info.has_lb && info.has_ub
    MOI.add_constraint(backend, MOI.SingleVariable(index),
                           MOI.Interval{Float64}(info.lower_bound, info.upper_bound))
end

... as a slack variable would get created automatically to bridge it but that doesn't work when only integer variables are supported.

Indeed, in this case, the slack variable could be created integer but the slack bridge does not know it.

[odow]

Closed by #1533. Implementations should now forward names if the solver supports it.