Do-A-Thon: Using Julia's JuMP for energy system optimisation

Possible topics

In this workshop, we would look at:

  • existing energy system optimisation frameworks in Julia (see tentative list below)

  • discuss best practices of implementation of energy system models in JuMP (for instance, how to write constraints while maintaining numerical performance)

  • discuss ways to cooperate development-wise between projects, including:

    • common high-level specifications
    • preferred Julia packages
    • use of frictionless data packaging and also agreement on schemas
    • perhaps the use of common or at least similar internal data structures
    • some kind of component architecture, possibly heading towards a software framework that projects can draw upon as they wish
    • preferred toolchain elements and software engineering practices
    • preferred design and documentation practices, including the use of UML
    • some agreement on coding and perhaps even naming conventions
  • thoughts on establishing a common codebase at some level, possibly well below that of a modeling framework

Terminology: the phrase "modeling framework" seems to be what people have settled on to describe the codebases underpinning projects such as OSeMOSYS or Calliope. Other terms including "modeling environment" or simply "model". The concept of "framework" as used in this context differs from that of a "software framework" in the computer science sense.

Existing open models

  • PowerModels.jl — Julia/JuMP Package for Power Network Optimization; can do multi-period optimisation
  • PSA.jl — a partial implementation of PyPSA in Julia (currently being rewritten, may also be renamed)
  • Mimi — Integrated Assessment Modeling Framework
  • DICE2016inJulia.jl — a reimplementation of the famous DICE model
  • (DPSA.jl — dynamic power grid analysis library (also the subject of a talk at Zürich by Tim Kittel). This is not intended as a power system/grid optimization tool but will be used for dynamical stability analysis (e.g. frequency stability on second and subsecond scale).)
  • CalliopeJuMP.jl — a partial implementation of Calliope in Julia. Intention to completely rewrite in near future.
  • Joulia.jl partial implementation of former elmod (from TU Berlin) in Julia (currently in rewriting process) elmod is a dispatch model with DC-low flow


  • JuMP package — listing at the Julia Observer
  • JuliaOpt — a collection of optimization-related packages

Installing Julia

Small warning: It’s probably best to install from the binaries; debian/ubuntu packages are out of date and compiling from source didn’t work for Tom Brown on Ubuntu 16.04 LTS.


Dunning, Iain, Joey Huchette, and Miles Lubin (2017). “JuMP: a modeling language for mathematical optimization”. SIAM Review. 59 (2): 295–320. ISSN 0036-1445. doi:10.1137/15M1020575.


The following diagram (release 02) captures some of the sentiments shown in the editable posting above. It is certainly far from the final word but hopefully a useful way to think about some options and the depth of integration that might work. The “domain-specific frictionless data packages with schema” would clearly benefit from the energy data package do-a-thon. And a well designed “single common codebase” would not preclude another projects from using parts of its underlying design, perhaps components from its “shared software framework”. There are large challenges ahead to get much of this working well though. On the other hand, there is already some experience in the component approach by the oemof project. Robbie.

Integration spectrum for cooperating projects — some ideas for discussion


I really like the idea. However, I think despite a better and faster model it would be good if we could link this to the outcome of ‘standardization’ processes / do-a-thons.

Also with regard to comprehension of the model / software, model-coupling etc.

From Tom’s talk: possible speed improvements in JuMP over Pyomo/GAMS

Please feel free to add your notes as well. The reply should be editable.


  • Pyomo in Python (oemof, calliope, PyPSA)
  • JuMP in Julia (none)


  • PyPSA / Oemof / Calliope (pre-processing) – netCDF – JuMP framework – netCDF – PyPSA / oemof / calliope (post-processing)
  • “open heart transplant”: change the core and interface with existing pre- and post-processing in respective models



  • search for common constraints (such as energy conservation)
  • interfacing: data abstraction, object-orientation and UML
  • current model fragmentation problem
  • package use: AxisArray.jl


  • define processes to achieve common JuMP package
  • collect equations to implement in object oriented style
  • set-up rudimentary example (netCDF, common constraints, …)
  • create hashtag in the forum to keep discussion/work going
  • monthly jour fixe (phone conference)

Some coding advice:

  • conditional expressions should be placed outside JuMP constraint statements
  • explicit data typing can make Julia faster than Python
  • easier to include parallelized code in Julia
Text and images licensed under CC BY 4.0Data licensed under CC0 1.0Code licensed under MITSite terms of serviceOpenmod mailing list.