The need for copy_names

[odow]

copy_to has a copy_names argument:

MathOptInterface.jl/src/MathOptInterface.jl

Lines 127 to 135 in b391731

	copy_to(dest::ModelLike, src::ModelLike; copy_names=true, warn_attributes=true)
	Copy the model from `src` into `dest`. The target `dest` is emptied, and all
	previous indices to variables or constraints in `dest` are invalidated. Returns
	a dictionary-like object that translates variable and constraint indices from
	the `src` model to the corresponding indices in the `dest` model.
	If `copy_names` is `false`, the `Name`, `VariableName` and `ConstraintName`
	attributes are not copied even if they are set in `src`. If a constraint that

This also leads to things like

MathOptInterface.jl/src/MathOptInterface.jl

Lines 98 to 109 in b391731

	supports_incremental_interface(model::ModelLike, copy_names::Bool)
	Return a `Bool` indicating whether `model` supports building incrementally via
	[`add_variable`](@ref) and [`add_constraint`](@ref).
	`copy_names` is a `Bool` indicating whether the user wishes to set
	[`VariableName`](@ref) and [`ConstraintName`](@ref) attributes.
	If `model` supports the incremental interface but does not support name
	attributes, define
	```julia
	supports_incremental_interface(::MyNewModel, copy_names::Bool) = !copy_names
	```

The conceptual understanding of when and why these are used is a bit confusing.

It was added here, without much explanation of why:
#297

As far as I can tell, the reason this was added was because we want to add names to the cache of a CachingOptimizer but not the optimizer:

MathOptInterface.jl/src/Utilities/cachingoptimizer.jl

Lines 192 to 203 in b391731

	function _attach_optimizer(
	model::CachingOptimizer,
	copy_to::F,
	) where {F<:Function}
	@assert model.state == EMPTY_OPTIMIZER
	# We do not need to copy names because name-related operations are handled
	# by `m.model_cache`
	indexmap = copy_to(
	model.optimizer,
	model.model_cache;
	copy_names = false,
	)::MOI.Utilities.IndexMap

This leads to confusion:
#1225
and supporting names is hard:
#674

Why do we need copy_names? Can we just ask the optimizer if it supports names? And if so, shouldn't we set them? This would make optimizer errors much nicer instead of C21 was infeasible.

We already skip some attributes if they aren't supported, so why not copy?

MathOptInterface.jl/src/Utilities/copy.jl

Lines 151 to 162 in f08c78c

	if attr isa MOI.VariablePrimalStart ||
	attr isa MOI.ConstraintPrimalStart ||
	attr isa MOI.ConstraintDualStart
	# As starting values are simply *hints* for the optimization, not
	# supporting them gives a warning, not an error
	if !MOI.supports(dest, attr, supports_args...)
	@warn(
	"$attr is not supported by $(typeof(dest)). This " *
	"information will be discarded."
	)
	continue
	end

We should either:

• Remove copy_names
• Document why it is needed

[blegat]

IIRC, the reason is: In the context of CachingOptimizer, you don't want to copy names to the second layer even if it is supported for performance reason. I guess it's not specific to names but it applies to all attributes that are not needed for solving. However, if the optimizer is a file writer then it does not apply. Maybe dropping it silently if it is not supported is the right approach.

[odow]

for performance reason

I guess we should benchmark this. I'd be surprised if this was an issue. In general, it makes a lot of sense to push names to the bottom solvers if they support it.

Even for things like writing the model using Gurobi/CPLEX level file writers. Currently all the names are lost. There have been a few issues on Discourse about this.

Same with debugging IIS. I know @jd-lara has complained to me about CPLEX losing this information and only reporting the column index that was the problem, not the name. I can't find the issue for it though. It may have just been on WhatsApp.

If the cost off setting names in the solver is a bottleneck, we're doing something wrong. We could also encourage solvers that don't natively support constraint names to not support them and just use a CachingOptimizer to store them.

Related issue in JuMP: jump-dev/JuMP.jl#2655

I can see how this was complicated when we had names for variable constraints, but now that we don't a lot of the original motivations have gone.

[joaquimg]

Pushing names to xpress is prohibitive if you need performance.
I would guess it won't be the less performant in this sense since we have many open-source solvers.

[odow]

Pushing names to xpress is prohibitive if you need performance.

You could have an option in Xpress.Optimizer to ignore names.

It feels like making this decision at the JuMP/MOI/CachingOptimizer level is the wrong place because people have different needs.

[blegat]

We could also encourage solvers that don't natively support constraint names to not support them and just use a CachingOptimizer to store them.

Yes, definitely.

I can see how this was complicated when we had names for variable constraints, but now that we don't a lot of the original motivations have gone.

I agree, copying names for all variable bounds might also have been expensive.

I would guess it won't be the less performant in this sense since we have many open-source solvers.

Which open source solver supports name ?

It seems copying names if supported might be a good default but people may want to be able to disable it as an option to JuMP and then the CachingOptimizer.
We could generalize the filter we already have.
The downside is that it might be a lot when you just want to filter constraints to also hve to implement a method for moddel attributes, variable attributes ,...
So instead of passing a function, you would pass an object.
Then by default copy_attribute, copy_constraints, is true and you can implement methods to change this.
Another approach is for CachingOptimizer to wrap the cache in an MOi layer that filters out the names.
I did something similar in https://github.com/lanl-ansi/Juniper.jl/blob/master/src/filter.jl

This also covers the use case of the filter_constraint keyword so we could define a ConstraintFilter and replace MOI.copy_to(dest, src, filter_constraint = f) by MOI.copy_to(dest, MOI.Utilities.ConstraintFilter(src, f)).
That way, we are back to a copy_to without any keyword arguments.

[odow]

but people may want to be able to disable it as an option ... [and the rest]

This is overly complicated. If @joaquimg wants to skip names in Xpress, he can add an option to Xpress.Optimizer(copy_names = false).