Think about how to build StructJuMP models

[coroa]

StructJuMP allows to organize and separate the block structure of huge models. In a nutshell one creates variables and constraints on several StructuredModel instances, one of which is the master and several others which define the subproblems.

These instances can then be communicated to parallel solvers like PIPS or DSP.

Do we want to split the variables constraints of a single component? ie Generator dispatch being split from capacity? Are there multiple cuts one would like to make?

@fneum Thoughts?

[coroa]

Most importantly the JuMP model must be dis-entangled from the EnergyModel since with StructJuMP there might now be multiple ones. So, the standard form of build will accept a JuMP.AbstractModel on which it will create its @variable and @constraint!

[coroa]

build(::Component) was replaced by a more general in https://github.com/PyPSA/EnergyModels.jl/commit/31d13dff3a2614be6211fa65773e3b9cc8de78f2

addto!(::JuMP.AbstractModel, ::EnergyModel, ::Component)

which allows using different jump models per component. Not sure if that is good enough!

[fneum]

Support for PIPS-IPM interior point solver needs to be done if used: https://github.com/StructJuMP/StructJuMP.jl/issues/24

[fneum]

There are two interesting ways of structuring:

• in space: cut by subnetwork and maybe also where the AC-network is weakly connected.
• in time: cut by snapshot or group of snapshots. In this case investment variables should go in the parent model (more difficult).

One way could be to have addto!() for particular components and snapshots:

T = axis(c, :snapshots)
G = axis(c)
addto!(::JuMP.AbstractModel, ::EnergyModel, c, G[1], T[1])

which would be called in

addto!(::JuMP.AbstractModel, ::EnergyModel, c, G[1])
addto!(::JuMP.AbstractModel, ::EnergyModel, c, T[1])
addto!(::JuMP.AbstractModel, ::EnergyModel, ::Component)

Just a thought. I don't know how good it is and it would probably mess with the current structure a lot.

If one wants to separate the investment variables/constraints from dispatch variables/constraints it gets more messy:

addto!(::JuMP.AbstractModel, ::EnergyModel, c, G[1], T[1], investment_flag=true/false)

I am not sure if this is worth doing.

[coroa]

Ok, here's an idea, which I think solves this seemingly difficult problem cleanly and combines well New repr. of time (#14):

I did simplify my explanation above a tiny bit, the method signatures for the addto! function for each component like

function addto!(jm::ModelView, ::EnergyModel, c::Generator)
     @variable jm ...
     @constraint jm ...
end

and there is a

addto!(jm::JuMP.AbstractModel, m::EnergyModel, c::Component) = addto!(ModelView(jm, c), m, c)

connector, that automatically wraps the jump model in a small jump extension, which redirects where jump objects are stored and prefixes their names with <class>::.

Ok, that was all an unnecessary explanation, because the idea was not finished yet, it's still a bit WIP, but here's the current state:

• Let's create a new type, which holds the "process" data of a part of the full model, ie. the parameters of defining the subset (buses, snapshots, investment flag), the JuMP.AbstractModel, the variables/constraints.

  struct SubEnergyModel   # the name is still WIP
  model::EnergyModel
  subset
  jumpmodel::JuMP.AbstractModel
  objects
  end

Then, one could construct such SubEnergyModels

sm = SubEnergyModel(m, Dict(:buses=>some_buses), jm, Dict{Symbol,Any}())
addto!(sm::SubEnergyModel, ::EnergyModel, c::Component)

A typical addto! method would then do the axis calls on sm:

function addto!(sm::SubEnergyModel, ::EnergyModel, c::Generator)
   G = axis(sm, c)
   T = axis(sm, :snapshots) # To be changed to maybe `timeaxis`
   jm = ModelView(sm.jumpmodel, sm, c) # That's a detail the user should not have to know about

   @variable jm ...
end

Open questions:

• The distinction between EnergyModel and SubEnergyModel is fuzzy:
  1. A SubEnergyModel could also just be an extended EnergyModel. In that case this would fit in with #12 .
  2. In object oriented terms, EnergyModel would be the class and SubEnergyModel is something like an instance, a realization.

...