Add new consumption_power formula to the LogicalMeter

@matthias-wende-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

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

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:

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

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.

@thomas-nicolai-frequenz

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

@leandro-lucarella-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.

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

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.

@sahas-subramanian-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.

@cwasicki

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.

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.

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.

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

Navigation Menu

Repository navigation

Add new `consumption_power` formula to the `LogicalMeter` #250

What's needed?

Proposed solution

Use cases

Alternatives and workarounds

Additional context

28 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Add new consumption_power formula to the LogicalMeter #250

Description

What's needed?

Proposed solution

Use cases

Alternatives and workarounds

Additional context

Activity

ela-kotulska-frequenz commented on Mar 10, 2023

thomas-nicolai-frequenz commented on Mar 10, 2023

cwasicki commented on Mar 13, 2023

28 remaining items

cwasicki commented on Apr 5, 2023

thomas-nicolai-frequenz commented on Apr 6, 2023

david-natingga-frequenz commented on Apr 6, 2023

cwasicki commented on Apr 6, 2023

thomas-nicolai-frequenz commented on Apr 6, 2023

thomas-nicolai-frequenz commented on Apr 6, 2023

thomas-nicolai-frequenz commented on Apr 6, 2023

cwasicki commented on Apr 6, 2023

thomas-nicolai-frequenz commented on Apr 8, 2023

leandro-lucarella-frequenz commented on Apr 11, 2023

cwasicki commented on Apr 11, 2023

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

Add new `consumption_power` formula to the `LogicalMeter` #250