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

Thoughts on adding to MOI #103

Open
odow opened this issue Feb 3, 2021 · 5 comments
Open

Thoughts on adding to MOI #103

odow opened this issue Feb 3, 2021 · 5 comments

Comments

@odow
Copy link
Member

odow commented Feb 3, 2021

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

@guilhermebodin
Copy link
Collaborator

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
Copy link
Member Author

odow commented Feb 4, 2021

at least eliminate the JuMP dependent parts.

Are these the only JuMP parts?

# 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
Copy link
Collaborator

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
Copy link
Member

blegat commented Feb 4, 2021

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:

@matbesancon
Copy link
Contributor

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

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

4 participants