feat: add a TYNDP base network

[tgilon]

This PR builds on https://github.com/PyPSA/pypsa-eur/pull/1578 and https://github.com/PyPSA/pypsa-eur/pull/1637. It must be merged after.

Changes proposed in this Pull Request

Introduce a new base network using TYNDP 2024 data. This base network can be used with tyndp-raw as base_network. It models NTC transmission capacities between TYNDP bidding zones using unidirectional links. This implementation neglects KVL and is referred to as a transport model. This is consistent with the TYNDP 2024 methodology.

Overview of the base network

Here is the bidding zone shape file (resources/bidding_zones.geojson):

Here is the administrative shapes (resources/admin_shapes.geojson):

Here is the base network (resources/networks/base.nc) (explore):

Here is the base network (resources/networks/base.nc) as result of plot_base_network:

Here is the clustered network (no clustering allowed) (resources/networks/base_s_all.nc):

Here is the clustered network (resources/networks/base_s_all.nc) as result of plot_power_network_clustered:

Testing

I've tested snakemake --configfile config/test/config.tyndp.yaml. It run through but I didn't include it in the CI because it requires the full data bundle.

ToDo

• [x] Use a 1w cutout to test the full workflow using https://zenodo.org/records/15349674
• [x] Fix p_min_pu to 0 (using https://github.com/PyPSA/pypsa-eur/pull/1637)

Checklist

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

[tgilon]

@fneum To create a more relevant CI integration test for this feature, we would need to change the default test setting. By default, Belgium is used to reduce the data. This would not work here as Belgium has only one bidding zone. A good workaround would be to use a 1-week cutout, as suggested by @FabianHofmann. We can provide the data but must add them to the Zenodo.

[tgilon]

@coroa FYI

[fneum]

@fneum To create a more relevant CI integration test for this feature, we would need to change the default test setting. By default, Belgium is used to reduce the data. This would not work here as Belgium has only one bidding zone. A good workaround would be to use a 1-week cutout, as suggested by @FabianHofmann. We can provide the data but must add them to the Zenodo.

Can be found here now: https://zenodo.org/records/15349674/files/europe-2013-03-sarah3-era5.nc?download=1

[tgilon]

@fneum To create a more relevant CI integration test for this feature, we would need to change the default test setting. By default, Belgium is used to reduce the data. This would not work here as Belgium has only one bidding zone. A good workaround would be to use a 1-week cutout, as suggested by @FabianHofmann. We can provide the data but must add them to the Zenodo.

Can be found here now: https://zenodo.org/records/15349674/files/europe-2013-03-sarah3-era5.nc?download=1

Thank you @fneum , the test is already using it.

[tgilon]

A general question: To what extent does it make sense to build the TYNDP model within the PyPSA-Eur workflow? If the TYNDP data is complete, wouldn't it make more sense to have that as an independent workflow?

Asked differently: if you use TYNDP within PyPSA-Eur, what data is actually taken from PyPSA-Eur?

I'm not suggesting that we recreate the TYNDP within the PyPSA-Eur workflow. We have the Open-TYNDP therefore. However, I think that it would be useful to have access to the grid as modelled in the TYNDP 2024 inside PyPSA-Eur. This PR also paves the way for comparisons between the TYNDP 2024 and the OSM data clustered using the same resolution (thanks to https://github.com/PyPSA/pypsa-eur/pull/1578). This would mean that all the demand data would still come from PyPSA-Eur, for instance.

[tgilon]

Thanks for the revisions @tgilon!

Some minor aspects to iron out.

Thank you @fneum for the review! I've addressed all of your comments.