Better integration with JuMP + GSOC

[odow]

There is a pretty incredible amount of work here (docs are outstanding).

I haven't quite wrapped my head around all of the functionality you have, so my question is: what, if anything, can we add to JuMP to make this simpler?

@tomasfmg is doing a GSOC adding parameters to MOI. I think there is some overlap, particularly with https://pulsipher.github.io/InfiniteOpt.jl/stable/guide/expression/#Datatype-Hierarchy-1. At the very least, we should understand the differences so we're not duplicating a lot of work

cc @blegat @mlubin @joaquimg

[pulsipher]

Oscar,

Thanks for reaching out and for the kind works, it has been a lot of work to get to this point. For the most part, JuMP has been fairly straightforward to extend and most of the complexity in this code is trying to retain a lot of JuMP's flexibility while considering the complexities of interdependent variable types (e.g., a lot of variables depend on infinite parameters which complicates methods like deletion).

Before mentioning some additions that would be helpful, I should mention that we are about 90% complete with a major restructuring and enhancement that will be comprise v0.2.0 which greatly streamlines a lot of methods, implements a much cleaner data structure, increases performance, and will add implicit ODE/PDE support of arbitrary orders (thus closing the majority of the open issues). This overhaul also changes our variable type hierarchy by introducing a general variable reference that allows us to build expressions with a concrete variable type for better performance (and better JuMP compatibility) and we now use a dynamic mapping scheme to track which expressions are infinite.

With regard to JuMP, the following additions comprise most of my wish list:

• Extendable NLP support --> here we need an expression data structure to store our extended expressions in and then be able to later access to build the transcripted JuMP version (like what we can currently do with GenericAffExpr and GenericQuadExpr)
• JuMP containers that behave more completely like AbstractArrays --> features such as a consistent key structure, constructor support (e.g. [element_expression for i in container_keys] --> appropriate container type), etc. would be very helpful since we currently use a fair amount of code trying to account the various possibilities since a number of methods take a container of variable references as input.
• Make JuMP._math_symbol extendable to allow for the addition of more symbol types (e.g., ∩ and ~)
• Provide support for extensions like mine that wish to employ more than one variable type (e.g., like JuMPChance use to do)
• Provide a method to access and/or store the optimizer constructor and attributes stored throughout the MOI backend of a JuMP Model all at once --> this would be useful for constructing a JuMP Model backend (see https://pulsipher.github.io/InfiniteOpt.jl/dev/guide/optimize/#InfiniteOpt.clear_optimizer_model_build!-Tuple{InfiniteModel} for our current workaround)
• Provide a method to extract the list of variables stored in an expression
• Provide a method to extract the model given an expression (assuming it has at least one variable)
• Generalize methods like set_objective_coefficient, set_normalized_rhs, add_to_function_coefficient work for abstract models and variables.
• More extendable constraint addition methods (making it similar to the way that variable definition can be readily extended)
  • Make build_constraint more extension friendly by allowing abstract scalar/vector types with
    various arguments (like how build_variable can be extended)
  • Make @constraint more extension friendly in combination with the above
• Provide a way to inherent more queries for abstract models (i.e., provide useful fallbacks perhaps relying on a single accesser method) this would help to eliminate a lot of boiler plate code
• Provide complete documentation/template on how to extend JuMP (to help other extensions)
  • Examples of structuring abstract models
  • How to extend variable types
  • How to extend constraint types
  • How to extend the printing
  • How to solve it via a JuMP Model
  • etc.
  • I think our extension page provides a nice format https://pulsipher.github.io/InfiniteOpt.jl/dev/extensions/

I'll leave it at that for now, but I would be happy to discuss any of this in more detail. Feel free to email me to set something up (I believe you have my email).

[odow]

I spoke to @pulsipher offline. Here is a summary of the points, with links to open issues:

Extendable NLP support

jump-dev/MathOptInterface.jl#846

JuMP containers that behave more completely like AbstractArrays

jump-dev/JuMP.jl#2176
jump-dev/JuMP.jl#2117
jump-dev/JuMP.jl#1988

Make JuMP._math_symbol extendable to allow for the addition of more symbol types (e.g., ∩ and ~)

Low priority.

Provide support for extensions like mine that wish to employ more than one variable type (e.g., like JuMPChance use to do)

Approach taken in InfiniteOpt 2.0 is the way to go. Make one concrete model type with some internal state which dictates whether it is a normal decision variable, infinite decision variable, etc.

Provide a method to access and/or store the optimizer constructor and attributes stored throughout the MOI backend of a JuMP Model all at once --> this would be useful for constructing a JuMP Model backend (see https://pulsipher.github.io/InfiniteOpt.jl/dev/guide/optimize/#InfiniteOpt.clear_optimizer_model_build!-Tuple{InfiniteModel} for our current workaround)

I need to think more about this. Current hack is okay in near-term.

Provide a method to extract the list of variables stored in an expression

Should probably be implemented in InfiniteOpt for now.

Provide a method to extract the model given an expression (assuming it has at least one variable)

Should probably be implemented in InfiniteOpt for now.

Generalize methods like set_objective_coefficient, set_normalized_rhs, add_to_function_coefficient work for abstract models and variables.

jump-dev/JuMP.jl#2256

More extendable constraint addition methods (making it similar to the way that variable definition can be readily extended)

jump-dev/JuMP.jl#2246
jump-dev/JuMP.jl#2236
jump-dev/JuMP.jl#2227

Provide a way to inherent more queries for abstract models

Essentially, if you have an outer InfiniteModel with an inner JuMP.Model, provide automated tooling to forward queries from the outer model to the inner model. I don't see an easy way to do this at present. But it's on my radar.

Provide complete documentation/template on how to extend JuMP (to help other extensions)

Yes.

jump-dev/JuMP.jl#1062

[pulsipher]

@odow I am going to close this, since most of it has been addressed now. The only item that remains is making JuMP.Model a little more friendly as an inner model (better supporting query forwarding). But I can create such an issue on the JuMP repo.