Using coluna.jl with Mosek and MSK_RES_ERR_UPPER_BOUND_IS_A_NAN #793
Comments
|
Hey Henri! Nice to hear from you! Do I need a license to run MOSEK? If it's the case I'm afraid I won't be able to run the example. You're probably right. It's not the first time we face this issue. So I'll consider changing the way we maintain variable bounds and stick to the classic constraints (>= and <=) and stop the use of infinite. I just can tell you that we won't do this change before 0.7. We are currently stabilizing the algorithms. Could you run your instance with GLPK or Gurobi? |
|
Hi Guillaume, Yes, you'd need a Mosek license. I use an academic one. This error only occurs with Mosek (tested with GLPK and Gurobi). Thanks for your answer! Whenever I have time, I'll try to find a workaround or to understand exactly why this only occurs with MosekTools.jl. |
|
You can try to reproduce using this example: https://jump.dev/MathOptInterface.jl/stable/tutorials/example/ You'll have to replace the integrality constraint by an Interval. |
|
It seems that MosekTools.jl is indeed the one to blame here. using MathOptInterface
const MOI = MathOptInterface
using MosekTools
using GLPK
using Gurobi
optimizer = GLPK.Optimizer()
c = [1.0, 2.0, 3.0]
w = [0.3, 0.5, 1.0]
C = 3.2
x = MOI.add_variables(optimizer, length(c));
MOI.set(
optimizer,
MOI.ObjectiveFunction{MOI.ScalarAffineFunction{Float64}}(),
MOI.ScalarAffineFunction(MOI.ScalarAffineTerm.(c, x), 0.0),
);
MOI.add_constraint(
optimizer,
MOI.ScalarAffineFunction(MOI.ScalarAffineTerm.(w, x), 0.0),
MOI.LessThan(C),
);
for x_i in x
# # Gurobi | Mosek | GLPK
#MOI.add_constraint(optimizer, x_i, MOI.ZeroOne()) # OK | KO** | OK
#MOI.add_constraint(optimizer, x_i, MOI.Interval(0., 1.)) # OK | OK | OK
MOI.add_constraint(optimizer, x_i, MOI.Interval(0., Inf)) # OK | KO* | OK
# *error is "Mosek.MosekError(1391, "The upper bound specified is not a number (nan).")"
# **error is "LoadError: MathOptInterface.UnsupportedConstraint{MathOptInterface.VariableIndex, MathOptInterface.ZeroOne}: `MathOptInterface.VariableIndex`-in-`MathOptInterface.ZeroOne` constraint is not supported by the model."
end
MOI.optimize!(optimizer)I will create an issue for MosekTools.jl. |
|
Great, thanks for checking! I close this issue and open a new one for the variable bounds. |
Describe the bug
When using a branch-and-price algorithm to solve Generalized Assignment Problem instances with Mosek as an external solver, an error is thrown.
ERROR: LoadError: Mosek.MosekError(1391, "The upper bound specified is not a number (nan).")This error relates to error
MSK_RES_ERR_UPPER_BOUND_IS_A_NAN(https://docs.mosek.com/10.0/opt-server/response-codes.html).This, I guess, happens when a bound is set to a non numerical value (e.g., +inf ?). Since every variable is bounded in GAP, I suspect this to come from artificial variables. Indeed, the stack shows that
solve_masteris being called before the error is thrown, as well asenforce_bounds_in_optimizer.Here is the complete trace.
To Reproduce
A working example can be found here.
Expected behavior
I would expect coluna not to fail. In other words, that the conveyed bound be checked before calling
add_constraintagainst nan values.Environment (please complete the following information):
Pkg.add("Coluna").The text was updated successfully, but these errors were encountered: