DISCUSSION: Bufferable, shiftable and mandatory load

[ChaelKruip]

The purpose of this ticket is to document and facilitate discussion on how we want to treat the various types of load in ETMoses.

Problem description

We have different types of load generating entities in ETMoses:

• PV panels: production, not shiftable, can be 'curtailed' when 'load management' is 'on'.
• EV: consumption and production, different behaviour depending on 'storage' and 'load management' buttons. Have a profile.
• Heat pumps: similar to EV but without the production (no way to discharge electricity). Have a profile.
• Batteries: consumption and production, different behaviour depending on 'storage' and 'load management' buttons. No profile.
• P2H: consumption, different behaviour depending on 'storage' and 'load management' buttons. Have a profile.
• P2G: consumption, different behaviour depending on 'storage' and 'load management' buttons.
• Base-load: consumption, different behaviour depending on 'load management' buttons. Have a profile.

We need a way to define the behaviour of these technologies in the following cases:

Storage	Load management
Off	Off
On	Off
On	On
Off	On

Principle

I think we should (at least at this point) stick to the following principles as much as possible:

• Base decisions on information that is available in the present Perhaps we will need to think about 'predicting' congestion etc. at some later stage but for now that is too complex a topic IMO.
• Describe behaviour explicitly and transparently It should be tractable which technology does what at every time (in principle).

  Possible solution-direction

  'Merit order' for technologies

A possible (not necessarily best) first step to bring some order into the above is by ordering the types of technologies in something of a 'merit order'. Smarter/more flexible technologies should come after more 'stupid' load to be able to react to the situation that is emerging after the dumb technologies have done their thing.

My initial ordering (dumb to smart/priority):

• PV production (not really that dumb but probably nice to know what production you have)
• Inflexible load (base-load and other technologies that we will identify to be inflexible)
• P2P batteries
• EV
• P2H
• P2G

Note that P2H and P2G are not necessarily smarter than P2P (batteries and EV) but the latter will likely be more useful to deploy first as it is better to store electricity than to convert it into another carrier with lower exergy.

NB: We could make this order to be user definable at some point.

Clear decision-tree for technologies

I think that each technology (or group of the same technologies) should decide what to do based on a its profile and some strategies that can be chosen by the user. To be more concrete, EV's decision making process could be as follows:

if "profile dictates that I must charge":
   load with full capacity
elif "there is excess production" and "storage is 'on'":
   load with full capacity
elif "there is some room on the network" and "load management is 'on'":
   load with capacity allowed by room on the network
elif "there is some demand" and "I have some spare charge" and "storage is on":
   discharge with needed capacity (if not exceeding max)
else:
   do nothing

For heat pumps, the decision making is very similar. The only difference is that discharging of electricity is not possible.

Decisions are based on strategies that can be added/modified easily later

The above decision-tree leaves room for some nice generalisation I think:

if "profile dictates something":
   action
elif "strategy_1 applies" and "strategy_1 == True":
   other action
elif "strategy_2 applies" and "strategy_2 == True":
   yet another action
...
etc
...
else:
   do nothing

This will help us to add, combine and order strategies later on. Even let the user order and combine them?

@antw @dennisschoenmakers @jorisberkhout please share your opinions and own ideas!

[antw]

I'll take some time to digest this – and its implications on the calculation – but in principle I think the Merit-style approach would be a move in the right direction.

I'm going to give this a try and will add more feedback shortly.

[dennisquintel]

I think the challenge here is that we want to keep flexibility in the number of Strategies (how to 'solve' the load on the network) but also keep the flexibility in the number of Technologies.

If we will define the rules per technology, we will end up with a 'problem': later if we want to add another 'strategy': this will create the immediate need to add more to the technology. If we define a Strategy as a separate object, we will have to add a technology to every Strategy as we add technologies in the future.

        | Strategy 1     | Strategy 2
-----------------------------------------------
PV      |   rules        |    rules
P2P     |   rules        |    rules
EV      |   rules        |    rules
P2H     |   rules        |    rules

I think this calls for a good think about the correct design pattern.

[ChaelKruip]

Closing.