Add new consumption_power formula to the LogicalMeter

[leandro-lucarella-frequenz]

What's needed?

We need to provide a consumption_power metric in the LogicalMeter.

Proposed solution

The LogicalMeter should get a new formula/metric consumption_power would calculate the client/market-side consumption of the microgrid. This should also include consumptions of EV chargers (but of course exclude PVs, batteries, etc.).

Use cases

No response

Alternatives and workarounds

Right now users need to look at the microgrid topology themselves to make this calculation, excluding batteries, PVs, etc.

Additional context

The name is still to be decided, so the issue is blocked until then. In your hands @matthias-wende-frequenz @frequenz-floss/datasci-team

[ela-kotulska-frequenz]

Is this what you need?
https://github.com/frequenz-floss/frequenz-sdk-python/blob/v0.x.x/tests/timeseries/_formula_engine/test_formula_composition.py#L147-L154

[thomas-nicolai-frequenz]

would calculate the client/market-side consumption of the microgrid

Its important to correctly define of what net consumption means. In the past we usually referred to it as market load, however net consumption is the consumption of none-flexible consumers that can't be shut down. EV chargers are obviously a hybrid but we agreed to include them into the net consumption for now, opposite to PVs, CHPs and batteries. The main goal is to:

1. Have one place where net_consumption is being defined
2. Have a common understanding of what net_consumption means (definition)

[cwasicki]

These are the definitions we agreed on:

$P_S$ : Production power
$P_L$ : Consumption power
$P_G$ : Grid power
$P_B$ : Battery power
$P_L+P_S$ : Net Consumption power

Note:

• This uses Passive Sign Convention.
• For now EV is part of consumption only, in future EV will be treated as a battery.

[shsms]

So the logical meter will eventually provide streams for:

1. grid_power
2. grid_current (used by the ev charging actor, probably also in other safety scenarios)
3. net_consumption

Does that sound accurate?

I can get used to it if it makes sense to every one else, but to have types of metrics (current and power) in the names for some streams, and the word "consumption" in a similar context for another stream, feels a bit inconsistent and awkward to me.

[thomas-nicolai-frequenz]

and the word "consumption" in a similar context for another stream, feels a bit inconsistent and awkward to me.

Well the problem is net_consumption is >0 but grid_power can be <>=0. So grid power can report consumption or production at any point in time whereas net_consumption is only whats being consumed.

[shsms]

I think the word power signifies that it is a derived quantity measured in W, not that it is flowing in both directions. Even when it is a single direction, it is the power value measured in W.

consumption provides a direction, but takes away info about what quantity is being measured. It could be either power or current.

Also, later on, if we want to introduce a net_consumption_current data stream, with 3-phase current values, would we then rename net_consumption to net_consumption_power, to disambiguate?

[thomas-nicolai-frequenz]

consumption provides a direction, but takes away info about what quantity is being measured. It could be either power or current.

true. good point.

then rename net_consumption to net_consumption_power, to disambiguate

Sounds like a good idea for sure.

[cwasicki]

@shsms Right, it should be net_consumption_power. Net consumption refers to the component, not the quantity. See #250 (comment) for the proposed definitions. But I see that this can be confusing. Do you have a better suggestion?

[leandro-lucarella-frequenz]

For me the net is not helping much and it is lacking who's consuming, I guess you already discussed this, but what about client_consumption? Or some other term that conveys that this is what the actual client is consuming, maybe productive consumption? Also supply sounds more like production to me, supply for me is more ambiguous and I would find it reasonable that the grid_power can be supply too (when it is supplying).

[leandro-lucarella-frequenz]

Maybe local_production and local_consumption? (then with _power or _current or whatever suffix)?

[shsms]

@cwasicki no, my problem was that the ticket just said net_consumption. If we can say net_consumption_power, then I don't think it is confusing anymore.

[cwasicki]

@shsms @leandro-lucarella-frequenz
@thomas-nicolai-frequenz and I had another discussion about the terminology, apparently there was a misunderstanding. I have update comment #250 (comment) to reflect the new terminology. Notably:

• Net consumption is the combination of Production and Consumption. This is also in line with the traditional terminology in this field.
• We think that the term production instead of supply has lower chances of confusion (also w.r.t common terminology in the energy market).

Let me know in case you still have doubts.

[thomas-nicolai-frequenz]

and consumption is net_consumption - pv_production - chp_production - battery ... assuming that pv_production is a negative value. The question is just if in the SDK we want that to be a negative value or a positive value too. If its a positive value the equation would be net_consumption + pv_production + .... Not sure which way we want that to be. Keep in mind if we opt to use battery.charge(...) and battery.discharge(...) values would be positive in both cases. Its certainly a tricky one.

[thomas-nicolai-frequenz]

So the logical meter will eventually provide streams for: grid_power, grid_current (used by the ev charging actor, probably also in other safety scenarios), net_consumption

1. grid_power (LogicalMeter that abstracts away the position of grid side meter etc.)
2. grid_current
3. consumption_power ( = grid_power + pv_power + chp_power + battery_power + ev_power .... ; can't be smaller than 0)

And in case we want to mirror the DSO meter (one meter in each direction) output we could also expose:

4. grid_consumption_power (if grid_power > 0)
5. grid_production_power (if grid_power <0)

[shsms]

And in case we want to mirror the DSO meter (one meter in each direction) output we could also expose:

net_consumption_power (if grid_power > 0)
net_production_power (if grid_power <0)

So these methods just split the grid power into two based on direction? Do we need to make them consistent by doing one of:

1. grid_power, grid_consumption_power, grid_production_power
2. net_power, net_consumption_power, net_production_power

[tiyash-basu-frequenz]

And in case we want to mirror the DSO meter (one meter in each direction) output we could also expose:

grid_consumption_power (if grid_power > 0)
grid_production_power (if grid_power <0)

Do we actually have a use-case for this? Asking because we did this initially in the microgrid API, but it did not prove to be as helpful as we thought (and rather problematic). A single signed value conveys the same information, and can be clipped pretty easily.

[thomas-nicolai-frequenz]

Do we actually have a use-case for this? Asking because we did this initially in the microgrid API

DSOs measure and report consumption and feed-in separately. To be able to easily compare the data these shortcuts might become handy. This is just a convenience feature and is independent of the API. That goes along the lines of the discussion of battery.charge(10) and battery.discharge(10) vs. battery.set_power(10).

[thomas-nicolai-frequenz]

True. The same argument also applies to production

Not sure I necessarily agree. What is the opposite of supply (supplying someone vs. being supplied)? For production its easy, its consumption and these are terms that everyone understands. Keep in mind we want to open up electricity to a wider audience and the terminology in this space has been set up a long time ago and thus many terms are way passed their time. We should be mindful not to repeat the mistakes of the past.

[cwasicki]

Updated proposal:

• Terminology follows {component}_{quantity} and {component}_{consumption,production}_{quantity}.
• Components are: grid, battery, consumer and individual active components pv, chp, wind.

Using the example of power:

• grid_power: Can be positive (consumption from the grid) or negative (production into the grid).
• {battery,ev}_power: Can be positive (charge battery) or negative (discharge battery). Equivalently for EV charging station.
• {pv,chp,wind}_power: Active components, the power from local (renewable) generation. Negative if electric power is generated, otherwise zero or positive in case of self-consumption of the generator. (alternative terms: generation, supply, source, active)
• consumer_power: This aggregates the remaining parts not covered by the above metrics. Under normal circumstances this is expected to correspond to the gross consumption of the site excluding active parts and battery. The implementation should still support negative values to also handle exotic site topologies (e.g. unidentified generators) and sudden short-term effects. (alternative terms: load, demand, sink, passive)

In addition to that, for each of the above there will two additional metrics:

• {component}_consumption_power: Positive power value if {component}_power is positive, otherwise zero.
• {component}_production_power: Positive power value if {component}_power is negative, otherwise zero.

Remarks:

• Gross consumption: Consumption before accounting for any local generation from solar, wind or CHP.
• Net consumption/load: This term traditionally refers to the difference between the gross electricity consumption and the local generation (like PV production). This is the electricity consumption that needs to be met by the battery or from the main grid. This means consumer_power + {pv,chp,wind}_power (note that latter is negative when electricity is produced). Since this term caused confusion in the past, it's not included in this proposal.
• Residual consumption/load: In microgrid context sometimes used as the remaining difference between the net consumption and the battery power, i.e. what we define as grid power.
• Consumer: Term deliberately chosen to indicate that this component is expected to predominantly consume electric power. Under normal circumstances there should be no active sources in this metric and the metrics consumer_{consumption,production}_power would not be used.

@thomas-nicolai-frequenz @shsms @leandro-lucarella-frequenz @tiyash-basu-frequenz

[thomas-nicolai-frequenz]

Just to add some more context to the term residual. There are a few more definitions that we should be aware off:

• Residual load
• Residual capacity
• Residual energy

@leandro-lucarella-frequenz we need to find a good place in the SDK wiki where we explain each of the terms. I feel its quite important to clearly define and explain it.

[david-natingga-frequenz]

What about EV charging stations? It should be a component in the same position like a battery: evc_station.

[cwasicki]

What about EV charging stations? It should be a component in the same position like a battery: evc_station.

Good point, for now we cover it in consumer since these are currently only consuming. In future they would be treated as a battery. But not sure if we will need a dedicated ev_battery component for this?

Just to add some more context to the term residual

Residual load is mostly used in context of the large grid where it is the electricity demand minus fluctuating renewable generation (https://de.wikipedia.org/wiki/Residuallast). On microgrid-level the usage seemed a bit vague so I would avoid a strict definition for us. Just added it for context since we discussed about it.

[thomas-nicolai-frequenz]

But not sure if we will need a dedicated ev_battery component for this?

No, EV chargers will stay being their own component category but will most likely derived from the same interface as the battery component. @sahas-subramanian-frequenz is aware of that. We did already discuss that.

[thomas-nicolai-frequenz]

Good point, for now we cover it in consumer since these are currently only consuming.

@cwasicki I don't mind carving them out to be honest. It wouldn't make much difference I guess and might avoid needing to restructure the code in the future if we want to keep things more clean. Your call.

[thomas-nicolai-frequenz]

On microgrid-level the usage seemed a bit vague so I would avoid a strict definition for us.

I think we should define it rather not defining it in the context of microgrids if we can. It opens up the possibility that we can shape the usage of this term in a way we feel its correctly applied. I think it would be dangerous to not talk about it.

[cwasicki]

@cwasicki I don't mind carving them out to be honest. It wouldn't make much difference I guess and might avoid needing to restructure the code in the future if we want to keep things more clean. Your call.

Agree, update the proposal to include ev_power equivalent to battery_power.

I think we should define it rather not defining it in the context of microgrids if we can. It opens up the possibility that we can shape the usage of this term in a way we feel its correctly applied. I think it would be dangerous to not talk about it.

I agree that we should document it, but wouldn't encourage its usage or include the term in the proposal since it does not describe a new concept but would be just another term for grid_power. Of course we could swap the two terms since latter is also not ideal, but overall I would stick to one term only.

[thomas-nicolai-frequenz]

but would be just another term for grid_power

lets just mentioned it when we define grid_power. lets add this to the public wiki.

[leandro-lucarella-frequenz]

@leandro-lucarella-frequenz we need to find a good place in the SDK wiki where we explain each of the terms. I feel its quite important to clearly define and explain it.

We could put it in the https://github.com/frequenz-floss/frequenz-sdk-python/wiki/Glossary, or it's own Wiki page for now. In the end I think it should be in the SDK documentation website (https://frequenz-floss.github.io/frequenz-sdk-python/v0.19/), but for now a Wiki page should be enough.

But I think it would be best if this doc is started by the people creating these definitions.

[leandro-lucarella-frequenz]

We could put it in the frequenz-floss/frequenz-sdk-python/wiki/Glossary, or it's own Wiki page for now. In the end I think it should be in the SDK documentation website (frequenz-floss.github.io/frequenz-sdk-python/v0.19), but for now a Wiki page should be enough.

Talking about this with @cwasicki, probably these definitions should also be put as part of the logical meter/battery pool/etc. documentation.

We might still want to put a summary somewhere in the frequenz.sdk.microgrid module documentation.

I guess for now the safest option is to put in the Wiki, but maybe it is something to include in the issues we create from this discussion @sahas-subramanian-frequenz

[leandro-lucarella-frequenz]

• Document the terminology used around consumption and production #319

[cwasicki]

Unblocking this issue again.

We could put it in the https://github.com/frequenz-floss/frequenz-sdk-python/wiki/Glossary, or it's own Wiki page for now. In the end I think it should be in the SDK documentation website (https://frequenz-floss.github.io/frequenz-sdk-python/v0.19/), but for now a Wiki page should be enough.

But I think it would be best if this doc is started by the people creating these definitions.

Moved this to #316

[leandro-lucarella-frequenz]

I actually converted this issue (the original) to a discussion, as it will be better to create new issues from the results of this discussion instead. The original issue description doesn't apply any more so it is better to create fresh issues with a clear scope.

[leandro-lucarella-frequenz]

@sahas-subramanian-frequenz can you create a new issue(s) only including what needs to be done based on the results of this discussion?

[thomas-nicolai-frequenz]

I think we are set here @leandro-lucarella-frequenz

[leandro-lucarella-frequenz]

👍 I will close the discussion when the new issues are created (or maybe @sahas-subramanian-frequenz can :)

[sahas-subramanian-frequenz]

yup, I will take care of it, will likely pick this up this afternoon.

[sahas-subramanian-frequenz]

Implementation will be tracked here: #340