Gurobi Error 10003: Name too long

Specific Domains Optimization (Mathematical)
, ,
1

So, I get the error that probably the variable (and likely constraints as well) have a name longer than 255 characters. I have some custom types that I use as indices of the variables. I am sure this is leading to the issue. However, I was wondering if there is a way around this problem. Having the objects of these custom types as variables indices make the formulation more intuitive. A MWE (rather poorly written but does reproduce the error) reproducing the problem is shown below:

using JuMP, Gurobi

struct Type1
    a::Int
    b::Int
end

struct Type2
    f::Vector{Type1}
end

struct Data
    g::Vector{Type2}
end

type1_vec1 = Type1[]
for i in 1:50
    push!(type1_vec1, Type1(i, i+1))
end

type1_vec2 = Type1[]
for i in 51:100
    push!(type1_vec2, Type1(i, i+1))
end

data = Data([Type2(type1_vec1), Type2(type1_vec2)])
model = Model(Gurobi.Optimizer)

@variable(model, y[v in data.g], Bin)

optimize!(model)

I understand that the error is generated by Gurobi software and not Gurobi.jl, but I am looking for suggestions on how to define indices if I actually want them to be custom type objects which can rather be lengthy. For example, a person object with lots of attributes. Also, I understand may be I can have a unique identifier for each object but then I have some objects that are automatically generated based on the user defined objects, so I am not sure to what extent I can keep defining these unique identifiers.

Thanks!

2

You can work around this with set_string_names_on_creation(model, false).

You could also explicitly set different names with set_name

1 Like
3

Hi @odow,

Thanks for referring to these links. This is immensely helpful. Just a follow-up question – When I set set_string_names_on_creation(model, false), I see that the variables are defined as anonymous variables. However, their indexing is still retained. So, I should still be able to access their values after optimization as usual. Right? For example, value(y[data.g[1]]), and so on. (I checked and it works but just confirming if I am thinking it correctly.)

So, if I understand correctly, setting set_string_names_on_creation(model, false), or giving some other name via set_name, only deregisters the default string name which eventually affects the name by which it is passed to the solver as well as how the user accesses the variable (or their values) later. Right?

Is there some example problem that showcases this functionality of accessing variable values and constraint expressions when the default name is set to off? This has always confused me for some reason, so I am looking to clarify all this. :sweat_smile:

Thanks.

4

Yes. The bindings are unaffected. All that changes is the string named used when printing. See

1 Like