Transition from stores to storage units for LTES, introducing energy-to-power ratio #1444

TomKae00 · 2024-12-05T09:13:18Z

Changes proposed in this Pull Request

This pull request introduces the following adjustments to the prepare_sector_network script:

Added PTES.
Transitioned stores to storage units for ltes, enabling the implementation of an energy-to-power ratio for these components.

The following config data has been used:

scenario:
clusters:
- 6

planning_horizons:
- 2030

foresight: overnight
countries: ['DE', 'DK']

clustering:
temporal:
resolution_sector: 12h

costs:
version: master

max_hours control:

The following figure illustrates the ratio of the state of charge compared to charging and discharging for the exemplary "DE0 0 urban central water pits". Additionally, the maximum hours are shown in relation to the ratio of the maximum state of charge to charging/discharging, demonstrating that the energy-to-power ratio is followed.

Effect of Changes: Results Analysis

Storage Sizing: stores vs. storage units

The transition from stores to storage units results in larger storage sizing:

Charging and Discharging Dynamics

The implementation of the energy-to-power ratio limits the charging and discharging rates relative to storage size. This is illustrated in the following plots:

Urban Central Water Tanks:

Urban Central Water Pits:

Energy Balances

The changes in charging and discharging dynamics influence the energy balance, as shown for urban central and urban decentral systems in the plots below:

Urban Central Heat:

Urban Decentral Heat:

Impact on Total System Costs

The shift from stores to storage units impacts the total system costs slightly, resulting in a small decrease in costs for the storage units compared to stores:

Checklist

[✓] I tested my contribution locally and it works as intended.
[✓] Code and workflow changes are sufficiently documented.
[✓] Changed dependencies are added to envs/environment.yaml.
[✓] Changes in configuration options are added in config/config.default.yaml.
[✓] Changes in configuration options are documented in doc/configtables/*.csv.
[✓] Sources of newly added data are documented in doc/data_sources.rst.
[✓] A release note doc/release_notes.rst is added.

…-power ratio

…network

for more information, see https://pre-commit.ci

config/config.default.yaml

cpschau · 2024-12-05T15:34:57Z

scripts/prepare_sector_network.py

+                "StorageUnit",
                nodes + f" {heat_system} water tanks",
-                bus=nodes + f" {heat_system} water tanks",
-                e_cyclic=True,
-                e_nom_extendable=True,
+                bus=nodes + f" {heat_system} heat",
                carrier=f"{heat_system} water tanks",
+                efficiency_store=costs.at["water tank charger", "efficiency"],
+                max_hours=costs.at[
+                    "central water tank storage", "energy to power ratio"
+                ],
+                efficiency_dispatch=costs.at["water tank discharger", "efficiency"],
+                p_nom_extendable=True,
                standing_loss=1 - np.exp(-1 / 24 / tes_time_constant_days),
                capital_cost=costs.at[
                    heat_system.central_or_decentral + " water tank storage", "fixed"
                ],
                lifetime=costs.at[
                    heat_system.central_or_decentral + " water tank storage", "lifetime"
                ],
+                e_nom_extendable=True,
+                e_cyclic=True,
            )


We might need another case distinction for different sizes of water tanks (DEA's "large hot water tank" for urban central heat and "small scale hot water tank" for urban decentral and rural heat), as the DEA provides different energy-to-power-ratio and costs. This would require additional changes in technology-data.

Yes, I was thinking that as well. Assuming a single E2P ratio might be very restrictive.

cpschau

Hi @TomKae00,
the implementation looks fine to me. However, the data behind it seems to contain some wrong assumptions that probably sneaked in with the recent changes in the technology-data repository, namely #144 and #152. In my opinion, we should assume (dis-)charger efficiencies of 1, as they are stated in the DEA catalogue. The indicated round-trip-efficiency-losses are probably chosen to give a proxy for the average standing losses. The standing losses, however, are already represented in our model by the configurable parameter tes_tau. Therefore, we would withdraw them twice according to the current implementation. These losses are probably also the reason, why PTES expansion decreases so heavily in your comparison between former "Store" and "StorageUnit" implementation and the total system costs change so much. To fix this issue, I would suggest to

submit a new PR in technology-data that refers the right charger- and discharger efficiencies for tanks and pits (maybe keep the round-trip efficiency as extra-row for people using technology-data without modelling standing losses separately),
ask @lkstrp to bump a new technology-data release, as soon as it is merged,
and finally reference the newly release version in the config.default.yaml.

As mentioned in the in-line review, it could also make sense to add the small scale hot water tanks to the technology-data to serve as decentral heat storage option, unless there are arguments against it @amos-schledorn

EDIT: decentral water tank storage are already part of the costs tables, taken from the PyPSA cost assumptions, so no need to add them.

for more information, see https://pre-commit.ci

amos-schledorn · 2024-12-18T16:52:39Z

Hi @TomKae00, the implementation looks fine to me. However, the data behind it seems to contain some wrong assumptions that probably sneaked in with the recent changes in the technology-data repository, namely #144 and #152. In my opinion, we should assume (dis-)charger efficiencies of 1, as they are stated in the DEA catalogue. The indicated round-trip-efficiency-losses are probably chosen to give a proxy for the average standing losses. The standing losses, however, are already represented in our model by the configurable parameter tes_tau. Therefore, we would withdraw them twice according to the current implementation. These losses are probably also the reason, why PTES expansion decreases so heavily in your comparison between former "Store" and "StorageUnit" implementation and the total system costs change so much. To fix this issue, I would suggest to
1. submit a new PR in technology-data that refers the right charger- and discharger efficiencies for tanks and pits (maybe keep the round-trip efficiency as extra-row for people using technology-data without modelling standing losses separately),

2. ask @lkstrp to bump a new technology-data release, as soon as it is merged,

3. and finally reference the newly release version in the `config.default.yaml`.
As mentioned in the in-line review, it could also make sense to add the small scale hot water tanks to the technology-data to serve as decentral heat storage option, unless there are arguments against it @amos-schledorn

EDIT: decentral water tank storage are already part of the costs tables, taken from the PyPSA cost assumptions, so no need to add them.

Agreed, well done @TomKae00! I've opened an issue for the standing losses: #1459, so we can tackle that separately. This is good-to-go from my side as soon as the requested changes by @cpschau are addressed.

@lkstrp any chance we could we get that technology-data release?

cpschau · 2024-12-19T09:25:00Z

scripts/prepare_sector_network.py

                carrier=f"{heat_system} water tanks",
+                efficiency_store=costs.at["water tank charger", "efficiency"],
+                max_hours=costs.at[


TTES in district heating and decentral water tanks do not have the same EtP ratio.

cpschau

I noticed one more thing that needs to be adjusted.

cpschau · 2024-12-19T16:32:33Z

scripts/prepare_sector_network.py

+                    heat_system.central_or_decentral + " water tank discharger",
+                    "efficiency",
+                ],
+                p_nom_extendable=True,
                standing_loss=1 - np.exp(-1 / 24 / tes_time_constant_days),
                capital_cost=costs.at[


Capital costs are related to power not to energy capacity --> Conversion from €/MWh to €/MW using energy to power ratio.

cpschau · 2024-12-19T16:33:22Z

scripts/prepare_sector_network.py

+                    ],
+                    p_nom_extendable=True,
+                    standing_loss=1 - np.exp(-1 / 24 / tes_time_constant_days),
+                    capital_cost=costs.at["central water pit storage", "fixed"],


Same here. Capital costs need to be converted according to unit.

fneum · 2025-01-02T14:31:20Z

The argument for this change is that the E2P ratio cannot be freely optimized, implying that extremely high/low ratios would not be technically feasible, right?

This should make the total system costs slightly higher if all unit/efficiency/cost calculations are done correctly. I was first a bit surprised by the lower cost with StorageUnit solution.

As @cpschau pointed out, giving the model only one E2P option might be very restrictive. One could add multiple (e.g. three E2P options as separate StorageUnits). An alternative -- which I am not sure I would recommend -- would be to keep Store/Link combination and allow ranges of E2P ratios.

TomKae00 and others added 5 commits December 4, 2024 23:14

Add PTES and change stores to storage units to implement an energy-to…

5b29d43

…-power ratio

cleaned up unnecessary code

8ea2e96

Align Snakemake defaults in prepare_sector_network with main script

fc26291

Add release note for PTES and storage unit updates in prepare_sector_…

f3bfdee

…network

[pre-commit.ci] auto fixes from pre-commit.com hooks

b4e4e70

for more information, see https://pre-commit.ci

cpschau self-requested a review December 5, 2024 12:16

cpschau reviewed Dec 5, 2024

View reviewed changes

config/config.default.yaml Show resolved Hide resolved

cpschau reviewed Dec 5, 2024

View reviewed changes

cpschau requested changes Dec 5, 2024

View reviewed changes

TomKae00 and others added 4 commits December 17, 2024 18:16

Improved distinction between decentral and central water tanks

85c9445

[pre-commit.ci] auto fixes from pre-commit.com hooks

194761f

for more information, see https://pre-commit.ci

small change of code

ce80d90

small changes at docs/release_notes

c8b7d90

amos-schledorn self-requested a review December 18, 2024 12:38

amos-schledorn mentioned this pull request Dec 18, 2024

Update standing losses of thermal energy storage #1459

Open

cpschau reviewed Dec 19, 2024

View reviewed changes

fneum self-requested a review December 19, 2024 16:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Transition from stores to storage units for LTES, introducing energy-to-power ratio #1444

Transition from stores to storage units for LTES, introducing energy-to-power ratio #1444

TomKae00 commented Dec 5, 2024 •

edited

Loading

cpschau Dec 5, 2024

fneum Jan 2, 2025

cpschau left a comment •

edited

Loading

amos-schledorn commented Dec 18, 2024 •

edited

Loading

cpschau Dec 19, 2024

cpschau left a comment

cpschau Dec 19, 2024

cpschau Dec 19, 2024

fneum commented Jan 2, 2025

Transition from stores to storage units for LTES, introducing energy-to-power ratio #1444

Are you sure you want to change the base?

Transition from stores to storage units for LTES, introducing energy-to-power ratio #1444

Conversation

TomKae00 commented Dec 5, 2024 • edited Loading

Changes proposed in this Pull Request

max_hours control:

Effect of Changes: Results Analysis

Checklist

cpschau Dec 5, 2024

Choose a reason for hiding this comment

fneum Jan 2, 2025

Choose a reason for hiding this comment

cpschau left a comment • edited Loading

Choose a reason for hiding this comment

amos-schledorn commented Dec 18, 2024 • edited Loading

cpschau Dec 19, 2024

Choose a reason for hiding this comment

cpschau left a comment

Choose a reason for hiding this comment

cpschau Dec 19, 2024

Choose a reason for hiding this comment

cpschau Dec 19, 2024

Choose a reason for hiding this comment

fneum commented Jan 2, 2025

TomKae00 commented Dec 5, 2024 •

edited

Loading

cpschau left a comment •

edited

Loading

amos-schledorn commented Dec 18, 2024 •

edited

Loading