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

Store variables and constraints in separate dictionaries #2

Closed
coroa opened this issue May 27, 2019 · 2 comments
Closed

Store variables and constraints in separate dictionaries #2

coroa opened this issue May 27, 2019 · 2 comments

Comments

@coroa
Copy link
Member

coroa commented May 27, 2019

ie. be less magical about whether one is handling a variable or a parameter.

Maybe provide getters var/con.

@coroa
Copy link
Member Author

coroa commented May 28, 2019

There are three possible styles:

  1. Store them at the EnergyModels type:

    mutable struct EnergyModel <: AbstractModel
       components::Dict{Symbol,Component}
       subnetworks::Dict{Symbol,SubNetwork{EnergyModel}}
       buses::Dict{Symbol,Bus{EnergyModel}}
       variables
       constraints
       data::Data
       jump::Model
    end

    a) Use a flat dictionary below the EnergyModels object net.variables[(<class>, <var>)]. Let's call that PowerSimulations.jl-style; only that they keep a canonical model on which they do it and do not have the class complication, instead they have for instance :Pth for thermal dispatch, :Ph for hydro dispatch, :Pr for renewable).
    b) Use a stacked dictionary net.variables[<class>][<var>] and split the tuple; that's more like how PowerModels.jl does it.

  2. Add the variables and constraints dictionary instead to the component types, like

    struct Generator <: OnePort
       model::EnergyModel
       class::Symbol
       variables
       constraints
    end
  3. In the previous/current version, I used to store them on the JuMP model as: model.objDict[Symbol(class, :(::), var_name)], ie for example Symbol("onwind::p") unfortunately the separator :: is stupid to write. We might keep that additionally so that the JuMP model is self-contained.

coroa added a commit that referenced this issue Jun 3, 2019
…age (WIP)

Replaces difficult to maintain `@emvariable` and @emconstraint` macros by
on-the-fly generated thin JuMP extensions. Should be easy to maintain and
provide a similar set of features.

Fixes #2.
@coroa
Copy link
Member Author

coroa commented Jun 4, 2019

Less magical about constraint variables is unfortunately not possible using the current format of JuMP extensions.

We're storing variables and constraints side-by-side in an objects dictionary on each component (so a variant of option 2 above), basically JuMP's model.obj_dict is made local on each component, using the thin ModelView wrapper.

@coroa coroa closed this as completed in 31d13df Jun 4, 2019
coroa added a commit that referenced this issue Jun 19, 2019
Slightly reverses conclusions of #2.
coroa added a commit that referenced this issue Jun 19, 2019
Slightly reverses conclusions of #2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant