Skip to content

Implementation of co_optimization based optimizer satellite

Sander Rijnrequested to merge
38-co-optimization-satellite into main

Description

@C.DohDinga I've set up a bunch of things, but don't have the time and/or ready knowledge to complete it right now. Feel free to continue if you can.

There's probably a lot to refactor, naming to improve and tests to be added, but at least the functionality should be there.

The biggest hold-up was correctly passing the init_store_level into the co-optimization model for the given window. I tried implementing it based only on the information present in a single window, but that always ended up not working.

The main issue is that it's bloody hard to correctly keep track of how much of the still future flexible demand has already been satisfied. Ideally, this would be as simple as 1. add extra demand satisfied, 2. subtract 'deadline demand'. The problem is that the 'deadline demand' (as defined by the energy_store lower bound) has already been adjusted based on the previous window's init_store_level. Furthermore, the demand itself can come from multiple amounts of flexibility, which basically means parsing the configuration again. The easiest solution to reason about (to me) was to pre-calculate each end_use's energy_store feasible region lower bound, and to track the total amount of supplied demand (_end_use_tracking). The init_store_level can then be calculated by 'globally' doing _end_use_tracking[end_use] - _global_store_minima[end_use][cur_timestamp - 1]. (The -1 offset is needed to make sure we're comparing with the right value, and has been implemented in practise by prepending a 0 to the _global_store_minima to ensure it also works at t=0.

I'll probably spend a bit of time later on to make a nicer write up of some of these considerations to add to the documentation, but perhaps someone can come up with a better implementation before then.

Related Issues

Issues resolved by this MR:

Checklist

  • Formatting matches prescribed style
  • Tests pass
  • Code coverage does not decrease
  • New tests have been added for new code
  • User-facing changes have been listed in [CHANGELOG.md]
Edited by Sander Rijn

Merge request reports