Thoughts on adding to MOI

[odow]

What are the pros and cons of adding this as a submodule to MOI?

[guilhermebodin]

Pros

• Fewer packages to install when users need to use these features.
• Might be easier to maintain as more people actively watch MOI.
• Opportunity to rethink some decisions and be able to solve add constrained variables #27.
• Have deeper discussions about how to export KKT conditions.

Cons

• Might need a little bit of refactoring, at least eliminate the JuMP dependent parts.
• Can break dependent packages (BilevelJuMP and MaxminOPF) Should not be hard to solve.
• Lose all the tests that rely on solvers

[odow]

at least eliminate the JuMP dependent parts.

Are these the only JuMP parts?

Dualization.jl/src/dualize.jl

Lines 68 to 88 in 3a8bb08

	# JuMP dualize
	function dualize(model::JuMP.Model; dual_names::DualNames = EMPTY_DUAL_NAMES)
	# Create an empty JuMP model
	JuMP_model = JuMP.Model()
	if JuMP.mode(model) != JuMP.AUTOMATIC # Only works in AUTOMATIC mode
	error("Dualization does not support solvers in $(model.moi_backend.mode) mode")
	end
	# Dualize and attach to the model
	dualize(backend(model), DualProblem(backend(JuMP_model)); dual_names = dual_names)
	return JuMP_model
	end
	function dualize(model::JuMP.Model, optimizer_constructor; dual_names::DualNames = EMPTY_DUAL_NAMES)
	# Dualize the JuMP model
	dual_JuMP_model = dualize(model; dual_names = dual_names)
	# Set the optimizer
	JuMP.set_optimizer(dual_JuMP_model, optimizer_constructor)
	return dual_JuMP_model
	end

If so, it should be easy to move the MOI parts to MOI, and add these two functions to JuMP.

Lose all the tests that rely on solvers

This seems like a blocker, but couldn't we just write out the dual problems to a file and compare against stored solutions?

[guilhermebodin]

I think they are, very little indeed.

Yes, we can! Losing all tests that rely on solvers requires being more careful when adding new tests but it is not extremely necessary.

For me we can add it to MOI, maybe others have cons that I am not seeing.

[blegat]

I agree it could be moved to MOI at some point. It could allow adding a dualize keyword argument to JuMP (even if we could also add Dualization as a JuMP dependency).
We should have as conditions for MOI conditions to be merged in MOI that they are mature enough and have tests not relying on solvers so I would say these are blocking:

• dual inception creates more variables as we dualize #9
• add constrained variables #27
• Rewrite test with MockOptimizer
• Not rely on an inner layer of bridge and use an outer one instead to fix (Request to add support for PSD constraints in square form in future release #73)

  Dualization.jl/src/MOI_wrapper.jl

  Line 43 in 3a8bb08

  dual_problem = DualProblem{T}(MOIB.full_bridge_optimizer(MOIU.CachingOptimizer(MOIU.UniversalFallback(DualizableModel{T}()), dual_optimizer), T))

[matbesancon]

con is that we keep pushing new things onto MOI itself. Keeping lighter packages within the JuMP-dev org seems easier to improve upon and less overwhelming for users.

even if we could also add Dualization as a JuMP dependency

I would favour such solution, make JuMP a all-at-once bundle but keep MOI lighter

[odow]

I think the conclusion is no.