Implement rule based alternative to solph

[p-snft]

The possibility to have alternatives to solph is part of oemof's core design. At the Nov. '18 dev meeting the idea came up, to implement such an alternative that can directly model classical control strategies. This alternative should accept an EnergySystem based on the solph network structure.

Advantages:

• Simplicity to directly compare optimized results with the ones of a classical, rule-based control strategy
• Probably improved runtime when compared to global optimization
• No perfect foresight (maybe no foresight at all, needs to be decided)
• Would allow optimization of control strategies

Disadvantages:

• API changes in solph will have to be coordinated with the ones of the new class
• Will only allow dispatch calculation (no investments).

Alternatives:

• Translate the "management strategy" into system costs, so that pyomo uses this rules to find optimal solutions that comply with this strategy.

[p-snft]

Yesterday, we had a discussion on this topic. The participants include the persons who came up with the idea in the dev meeting. Here are the results (protocol by Bastian and me):

Goals of dynamic simulation

• increase temporal resolution
• improve computational performance
• develop control algorithms
• develop concepts for operational management
• eliminate problems with perfect foresight
• should be compatible with rolling horizon ansatz
• rolling horizon -> control algorithm

Option A

• stick with rolling horizon approach, but make it more accessible
• define time step, prediction horizon, feedback value
• limited foresight

Identified problems

• with the choice of short horizons (daily cycles) there will be no seasonal aspects considered e.g. seasonal storages -> Mix rolling horizon approach and priorities?
• How is flexible access to certain time steps to the controller realized (e.g. failure occurs)?
• Does not allow direct modelling of control strategies.

Option B

Properties

• no (internal) foresight
• time steps solved independently
• local balance following a hierachy (this requres a loop-free graph)
• dubbed "golph": Greedy Optimizer using Local Prioritization following a Hierarchy

Draft algorithm

• prioritize and match flows at buses: must: fixed=True target: negative price (= revenue) permit: positive price
• update values/ preference:
  • stop simulation every time step
  • model components externally:
    • finite state machine
    • physical system
  • comment: it might be useful to have time series in queues

Identified problems

• some situations might require looped graphs
  • cycled energy in transformer loops
  • simple workaround (for storages): decide to charge/discharge beforehand
• accumulated flows will have fixed and variable component
  • for many components, two flows are possible
  • but not for GenericCHP

To do

• Look into possible steady-state-flow solutions with python ("something like StateFlow").
• finalize development ideas and approaches until END OF JANUARY 2019

[longlevan]

+1 for having an rule-based alternative to solph