Last round of renaming

[mlubin]

Now that we've mostly settled on the MOI/MOIU/JuMP API structure, it's time to rename the different components to match what they do. Last time we do this before MOI is released.

Let's list the things we have:

• supports-MOI-interface describes a type that implements the MOI interface for specifying problems, i.e., addvariable!, addconstraint!, copy!. There are different levels of support, i.e., copy-only, 2-pass load, and general addconstraint!.
• data-with-optimize! is a supports-MOI-interface object that lets you call optimize!. The data are usually stored and owned directly by the solver.
• data-without-optimize! is a supports-MOI-interface object that does not support optimize!. It just stores the problem data.
• data-with-optimize!-plus-caching is a supports-MOI-interface object that lets you attach and synchronize with a data-with-optimize!. It stores an extra copy of the data and deals with the case of the data-with-optimize! not supporting the full MOI interface by re-copying the data to the solver when needed. In "automatic" mode, a data-with-optimize!-plus-caching can act exactly like a data-with-optimize! (Supertype of InstanceManager is AbstractSolverInstance JuliaOpt/MathOptInterfaceBridges.jl#65). In "manual" mode it gives more control over when copies happen, and you can't naively use it as a drop-in for data-with-optimize!.
• optimize!-attributes are gettable/settable attributes related to how optimize! works like stopping limits, solution methods, and the name of the solver (Add SolverName #201). These are dropped on copy!
• data-attributes are essential parts of the data specification (names, VariablePrimalStart, NLPBlock) that cannot be dropped on copy!.
• result-attributes are properties of the result computed by optimize!. I don't think we've discussed if they can be dropped on copy or not.

JuMP provides a frontend to any supports-MOI-instance object depending on what its moibackend field is set to. The default use case is for JuMP to be a frontend fordata-with-optimize!-plus-caching.

Currently:

• supports-MOI-interface is AbstractInstance
• data-with-optimize! is AbstractSolverInstance
• data-without-optimize! is AbstractStandaloneInstance
• data-with-optimize!-plus-caching is InstanceManager
• Attributes are a mix of AbstractSolverParameter and AnyAttribute (Add SolverName #201).

I'm going to throw out a couple questions to start the discussion. I don't have a full proposal yet, but hopefully this summary above will get everyone on the same page on the layout of the abstractions. I'd like to brainstorm and make a decision on this quickly so that we can make this change and move on!

Question 1: Looking at this now, the definition of data-without-optimize is a bit strange. Usually we don't define objects by what they don't support. Should we just remove this concept in favor of supports-MOI-interface? If we need to dispatch on data-with-optimize! and data-without-optimize! we can dispatch instead between data-with-optimize! and supports-MOI-interface.

Question 2: Do we want to call data-with-optimize! AbstractSolver? A documentation-level definition of a solver could be:

"A solver implements the MOI interface for loading problem data and supports optimize!".

This has a downside of being completely different from MPB's definition of a solver, but that's not a blocker. In the data-with-optimize!-plus-caching I found it convenient to talk about the "solver" and the "instance":

https://github.com/JuliaOpt/MathOptInterfaceUtilities.jl/blob/d9d1c4f20b1667e440b2a54831fefe8a117e433a/src/instancemanager.jl#L12

Note that any use of "solver" in MOI should be consistent with the use of solver= in JuMP.

Question 3: Can we make JuMP's Model somehow consistent with the MOI naming convention? JuMP is now essentially a nice interface to any supports-MOI-interface object. That would suggest picking a name for supports-MOI-interface that's similar to JuMP's Model, or renaming JuMP's Model.

@blegat @odow @joaquimg @chriscoey @joehuchette @ccoffrin @IssamT

[ccoffrin]

Quick question, is the use of dashes in names part of Julia style conventions? If not, I would make a case for underscores.

[mlubin]

The dashed names are not real names of Julia objects or anything that exists in MOI. I made them up so that we can talk about the current objects without getting confused about their names.

[blegat]

Question 1 : Defining objects on what they don't support isn't nice indeed. A solver could be used as the instance of the InstanceManager if it implements all MOI, the fact that it also supports optimize! doesn't make it unusable as an instance. I am in favor of removing AbstractStandaloneInstance.

Question 2 : AbstractSolver <: AbstractInstance with optimize!(::AbstractSolver) : solvers are instance that also implements optimize! seems perfect. The fact that it doesn't match MPB is not a big issue. InstanceManager should be an AbstractSolver then since it implements optimize! and the moibackend of JuMP should be AbstractSolver. Or we let JuMP also be used without solve, e.g. for being used for creating a file describing an instance, in this case we can leave InstanceManager as an AbstractInstance.

[odow]

Can we make JuMP's Model somehow consistent with the MOI naming convention?

Remember when we renamed everything from Model to Instance?

AbstractInstance -> AbstractModel
AbstractSolverInstance -> AbstractSolverModel
AbstractStandaloneInstance -> AbstractModel (see Q1)
InstanceManager -> ModelManager
AbstractSolverParameter -> AbstractSolverParameter

I don't necessarily think that the JuMP naming has to sync up with MOI. Trying some things out...

m = Model(solver = CbcSolver())    # good
m = Model(solver = CbcInstance())  # bad

m = Instance(solver = Cbc())       # good
m = Instance(base = CbcInstance()) # good

m = Model(base = CbcInstance()) # good?

[mlubin]

Or we let JuMP also be used without solve, e.g. for being used for creating a file describing an instance,

I think this could be a nice use case. I'd like to allow the moibackend to be a data-without-optimize!.

[mlubin]

@odow that proposal makes sense. A solver model is a kind of model.

On the JuMP side I'd propose:

• The backend= keyword directly sets the moibackend field.
• The solver= keyword sets up the data-with-optimize!-plus-caching with a given data-with-optimize!. We could even also accept strings like "Gurobi", "Clp".

[mlubin]

Model(solver = GurobiModel()) doesn't feel right, as @odow noted. We could say Model(solvermodel = GurobiModel()) but that's awkwardly long. Is there any shorter name we could use for data-with-optimize! besides solver model?

[joaquimg]

Gurobi C program holds data and is able to optimize and it calls itself a a state-of-the-art *solver* for mathematical programming.
Whats the reason we do not like to call it just a solver? Do we want to keep that for something more particular?
Maybe its bad because SCS is also a solver and it does not have a nice data modification API. But then MOISCS holds data and is able to optimize hence it falls in the same category of Gurobi C API.
On the user side solver looks nice. Does it convey the wrong idea in some cases?

[mlubin]

• It would be nice (but not necessary) to avoid a name clash with GurobiSolver(). If we do this it will make the transition path smoother so that MOI and MPB interfaces can be exported from the same package.
• Gurobi's native APIs have "environments" and "models". Gurobi "models" correspond to data-with-optimize!.

Maybe it's just me, but "optimizer" doesn't seem to have the same baggage as "solver". What about data-with-optimize! becomes AbstractOptimizer, and we have GurobiOptimizer?

m = Model(optimizer = GurobiOptimizer()) # Automatic mode with ModelManager
m = Model(backend = GurobiOptimizer()) # Direct mode
# And even, maybe:
m = Model(optimizer = "Gurobi")

Retiring the solver= keyword would be a plus, to avoid confusion during the transition.
I'd also propose AbstractInstance -> AbstractModel following @odow.

[tkoolen]

I'd like to propose renaming ListOfConstraints to ListOfConstraintTypes.

[mlubin]

@tkoolen I opened a separate issue for that so it doesn't get lost in this discussion

[blegat]

Does AbstractOptimizer <: AbstractModel works ? Can we say "An optimizer is a model" ?

[joaquimg]

What if we use AbstractModelOptimizer for the abstract type and the GurobiOptimizer for the concrete? I like optimizer. I also think Optimizer <: Model slighly weird, no big deal though.

[blegat]

AbstractOptimizerAttribute is better than AbstractSolverAttribute since it is really the optimize! attribute (attribute for the optimization algorithm, not the model)