Demand including export does not equal supply when electricity storage is installed

[mabijkerk]

When I open a blank scenario on beta, add 10.0 GW of flow batteries and turn the forecasting algorithm on, I get this scenario. The source of electricity production chart then shows a slight difference between total production and total demand (including demand for export).

It does not seem limited to flow batteries: if I install e.g. 10.0 GW of large-scale batteries with the forecasting algorithm on, instead of the flow batteries, the total demand including export (546.5 PJ) also exceeds total supply (544.6 PJ):

When I turn off the forecasting algorithm and adjust the prices to increase the utilisation of the large-scale batteries I get this scenario. In this case the total supply (549.0 PJ) exceeds total demand including export (548.4 PJ).

I don't think any series could be missing in the supply-side queries, since batteries only pass on the electricity of other sources of electricity. If need be I can look into the issue some more and try to pin down where it goes wrong exactly, but I'm also curious if you already might have an idea @antw.

[antw]

I'm pretty sure this would be fixed by https://github.com/quintel/etengine/issues/1218. I tested the last scenario with the MV battery, and the input and output curves have a significant mismatch. This implies that there's a lot of unused energy remaining in the battery at the end of the year. This mismatch is exactly the same as in the chart:

• Mismatch in the chart: 0.89665 PJ
• Mismatch in MV battery input and output: 0.8966532699810417 PJ

[mabijkerk]

Okay so that explains the mismatch for price-based behaviour, where there is unused energy left in the large-scale battery at March 31st. The total supply then exceeds total demand.

However, with the optimisation algorithm on you state that there should be no mismatch:

The new battery algorithm does not have this problem since it optimizes the battery across the whole year, rather than one hour at a time.

This therefore does not seem to explain the second example where, with the optimisation algorithm on, the total supply is lower than total demand. For reference this is the scenario.

[antw]

This therefore does not seem to explain the second example where

Thanks, this insight put me on the correct path. I'm using a simplified scenario for my examples:

• MV battery capacity: 10,000 MW
• MV forecasting: On
• MV willingness-to-pay: 50 EUR

Unfortunately, I've only got bad news:

• Output losses for battery forecasting weren't handled correctly. I've fixed this, but the outcome doesn't fix the mismatch. It changes the mismatch to be the other way around.

  

• The mismatch is not due to unused electricity, but the output losses of the MV battery (15%). The difference between the MV input and output curve is 1.9 PJ, caused by output loss. 1.9 PJ is also the mismatch between the "Demand (incl. export)" and "Total" figures.

It's useful to understand the difference between the two values in the chart:

• Demand (incl. export): Calculated using a query that sums the final demand for electricity in each sector, plus HV network losses.
• Total: Calculated in ETModel by summing the individual demands in the table (Coal, Coal gas, Natural gas, ...). These numbers come from the output of electricity from electricity producers.

Electricity flows

Excess electricity (including batteries) isn't connected in any way to the electricity network. Instead, we've got a completely disconnected subgraph where excess electricity ends up:

The "Demand (incl. export)" is querying the electricity consumption (final demand), while "Total" is querying production.

This isn't an issue because storage doesn't change the amount of electricity production or consumption. It changes when it is produced and consumed. The logic was that these nodes don't need to connect to the network because the electricity is already represented there.

(ignore for now that many excess electricity options should connect to the MV or LV network)

Losses

A moment ago, I said:

storage doesn't change the amount of electricity production or consumption

This is, of course, completely untrue:

1. Stored electricity can decay in some storage options.
2. Energy is sometimes lost when discharging.

These losses happen completely outside of the normal electricity network. Note how the amount of energy entering the HV network is 1.9 PJ higher than the energy that leaves. A producer has to output those 1.9 PJ to account for the MV battery loss but that loss isn't represented anywhere on the consumption side of the HV network.

The result is:

• The 1.9 PJ of loss is accounted for when querying electricity production, since some other producer has to step in to meet demand not met due to the battery loss.
• The 1.9 PJ of loss is not accounted for when querying electricity consumption as it doesn't happen on a node that is reachable from the consumer.

Solution

I don't think there is a solution aside from reconsidering how we structure electricity storage in the graph. I feel it should be connected to the electricity network, but I imagine this is non-trivial:

• Different storage options should be connected at different network levels
• We'd likely lose the excess electricity node in the process, meaning we have to change queries

I propose we combined this with #1218 into a full modeling project at some point. I don't see a quick fix.

---

Including @ChaelKruip.

[mabijkerk]

This is also related to https://github.com/quintel/etsource/issues/2493. It seems to me that the goal of that issue is indeed to lose the excess electricity node, which makes sense because flexible demand technologies are no longer limited to using only excess electricity.

The 1.9 PJ of loss is not accounted for when querying electricity consumption as it doesn't happen on a node that is reachable from the consumer.

At least for this chart, can't we query the losses in batteries and add them to electricity consumption query? Or would that be 'hiding' the current flawed calculations?

[github-actions[bot]]

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.