Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gurobi Error 10003: Name too long #576

Closed
resmaeilbeigi opened this issue Oct 18, 2024 · 8 comments
Closed

Gurobi Error 10003: Name too long #576

resmaeilbeigi opened this issue Oct 18, 2024 · 8 comments

Comments

@resmaeilbeigi
Copy link

So I got this error when solving a large model with Gurobi and worked around it through the method
mentioned in Gurobi Error 10003: Name too long.

I am raising it here to track the status of the issue.

JULIA_VERSION = 1.11.0
Gurobi v1.3.1
JuMP v1.23.2

Note that other solvers such as SCIP do not have this issue. Same for older versions of Gurobi/Jump i.e.,
the same model is solved without any issue with the following setup:

JULIA_VERSION = 0.6.2
Gurobi v0.4.0
JuMP v0.18.4
@odow
Copy link
Member

odow commented Oct 18, 2024

I guess we could be more permissive here:

ret = GRBsetstrattrelement(model, "VarName", Cint(info.column) - 1, name)
_check_ret(model, ret)

But the underlying issue is: why such long names?

@resmaeilbeigi
Copy link
Author

In my case it is a large constraint generated by
@constraint(model, basicCoverage[i in indices], ...), where i is a struct of the following form

struct Index
	a :: Number 
	b :: Set{String}
	c :: String
end 

The length of indices is large in practice, hence the issue (this is only one of the constraints in a large production model).

@odow
Copy link
Member

odow commented Oct 18, 2024

The issue is unrelated to how many elements there are in indices.

This issue is because JuMP creates a name for the constraint as: "basicCoverage[$i]". You almost certainly don't want this, because the default show(::IO, ::Index) method will serialize b into the name.

You should do one of the following:

  • Disable string names for the entire model as you have done
  • Disable string names for just this definition,
  • Use set_name to choose a more readable name
  • Define Base.show(io::IO, index::Index) = print(io, "index_$(index.a)") (or similar) so that it is more readable.

@resmaeilbeigi
Copy link
Author

Thanks. The constraint names are relevant mostly when there is infeasibility which then we use to check which indices are involved (there are normally tens of thousands of constraints). In the example above, knowing all field values of the index is needed. I know we can use some mapping etc to work around it, but doing any workaround is a lot of work given the large codebase, various constraints and the way infeasibility messages are generated.

It is worth mentioning that I got this issue when upgrading from Julia 0.6 to Julia 1.x (the codebase is developed over ~9 years). For now I have disabled string naming for every Gurobi model (the easiest solution for now) which needs to be resolved later.

@resmaeilbeigi
Copy link
Author

Just out of curiosity, I wonder why Gurobi.jl needs to set this limit on the name sizes even though the solver allows for such long names.

@odow
Copy link
Member

odow commented Oct 18, 2024

needs to set this limit on the name sizes even though the solver allows for such long names

The Julia package is not setting the size limit. It is the underlying solver that is throwing the error.

@resmaeilbeigi
Copy link
Author

resmaeilbeigi commented Oct 19, 2024

Ah I see. I got confused that there was no error in Julia 0.6 but it is failing in Julia 1.11 with the same solver version. Apparently the older version of Gurobi.jl did not store constraint names, but rather stored the name of the container of those constraints. Thanks for your help.

@odow
Copy link
Member

odow commented Oct 29, 2024

Closed by #580

@odow odow closed this as completed Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants