add energy storage interface

[pz-max]

Changes proposed in this DRAFT Pull Request

This is a draft pull request and not yet ready for review.

Goal: energy storage technologies will be added to the model only by selections and additions in config.yaml and certain data format in the costs.csv. This should avoid manual code additions in case technologies are added into studies. Examples of code additions that will be no more needed are add_electricity, add_extra_component and solve_network. This should save massive code duplication for technology-rich studies and complexity issues/ overhead for users.

Additional fixes:

• Enable to run monte-carlo in scenario management #598

Reproduction:

To test this interface certain steps are necessary until PyPSA/technology-data#67 is merged into the technology database.

1. Clone branch with technology interface: git clone -b store https://github.com/pz-max/technology-data.git
2. Compile costs: python scripts/compile_cost_assumptions.py
3. Copy in outputs e.g. costs_2030.csv
4. In PyPSA-Earth, set in config.yaml, retrieve_cost_data: true
5. Add manually costs.csv add following location pypsa-earth/resources/costs.csv
6. Now running e.g. ['concrete', 'pair', 'gravity'] as store or storage_unit should work

Status

• PR in technology data interface add >18 energy storage techologies PyPSA/technology-data#67
• Add helpers to convert metadata in dict() format into useful information
• Write generic function in add_electricity() to calculate capital_costs per storage_unit
• Write generic function in 'add_extra_components()` to attach storage_unit
• Write generic function in 'add_extra_components()` to attach store
• Write generic function for add_battery_constraints() in solve_all_networks for all bichargers written in store & links style
• For storage_units. Read by default max_hours from costs.csv and make overwrite in config.yaml possible. Requires parameter addition max_hours with unit h in costs.csv. Currently max_hours is arbitrarily used. The use of storage_units is hence not recommended yet.
• Config options such as tech-colors, storage_units etc. need to be dealt with for plotting
• Need to add a test in test/config.custom.yaml (needs that at least two storage technologies from interface are added to costs.csv e.g. bicharger and classical three component storage). Using the interface from technology_data still requires some time and we should not use that for testing atm...
• add cost ranges interface in case key:value exist for optimistic/pessimistic values, see suggestion [idea] having range of data instead of a single value? pz-max/energy-storage-data-explorer#2
• Clean up

Checklist

• I tested my contribution locally and it seems to work fine.
• Code and workflow changes are sufficiently documented.
• Newly introduced dependencies are added to envs/environment.yaml and envs/environment.docs.yaml.
• Changes in configuration options are added in all of config.default.yaml and config.tutorial.yaml.
• Add a test config or line additions to test/ (note tests are changing the config.tutorial.yaml)
• Changes in configuration options are also documented in doc/configtables/*.csv and line references are adjusted in doc/configuration.rst and doc/tutorial.rst.
• A note for the release notes doc/release_notes.rst is amended in the format of previous release notes, including reference to the requested PR.

[pz-max]

Optimization status: Failing.

1. Either the add_bicharger_constraint() in solve_networks.py is bad
2. Or any component was falsely allocated in add_electricity.py or add_extra_components.py

Number one will be tested in a case without store-link storage technologies -> remove technologies in config with name ["store"]. Because this won't trigger any storage constraints. Number two will be tackled with a solid review and debugging of n.add functions as well as component analysis e.g. n.store.

[pz-max]

Optimization status: Failing.

1. Either the `add_bicharger_constraint()` in `solve_networks.py` is bad

2. Or any component was falsely allocated in `add_electricity.py` or `add_extra_components.py`

Number one will be tested in a case without store-link storage technologies -> remove technologies in config with name ["store"]. Because this won't trigger any storage constraints. Number two will be tackled with a solid review and debugging of n.add functions as well as component analysis e.g. n.store.

Status: RUNNING
The problem was that one is not allowed to have the same carrier in the store & storage_unit at the same time. A little check would be helpful.

[pz-max]

These store and storage_unit technologies can now be modelled between 2020-2050 (&beyond):
['concrete', 'pair', 'gravity', 'gravitywa', 'gravitywu', 'salthight', 'h2cavern', 'lead', 'lair', 'lfp', 'nmc', 'saltlowt', 'nizn', 'phes', 'phs', 'sand', 'vanadium', 'znair', 'znbrflow', 'znbr']
Technologies are documented in the technology_data repo. See above.

Testing in combination with global sensitivity analysis aka. Monte-Carlo now.

[pz-max]

Working on a stacked PR: pz-max#1
to add the feature which aims to eventually filter out unnecessary technologies

[pz-max]

@davide-f I think we should keep this as PR until I submit my dissertation. The current status is sufficient for my PhD, but requires some changes before merge (see description). In general, I don't expect much more changes so the PR won't grow much.

[pz-max]

Hi @davide-f, we already had a review iteration. Not sure about this bit @davide-f . I will check this PR over the next weeks and ping you if there is a review needed. It would be good to get this monster merged during the next month.

[pz-max]

This PR is currently paused because of issues with time commitment.
The PR was used in this preprint as part of my PhD thesis.
Please ping me here if you would like to work on energy storage and give it another try with this PR.