increase transmission limit in each myopic run

[martacki]

Closes # (if applicable).
#1917

Changes proposed in this Pull Request

see the linked issue

Checklist

• I tested my contribution locally and it works as intended.
• Code and workflow changes are sufficiently documented.
• Changed dependencies are added to pixi.toml (using pixi add <dependency-name>).
• 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.

[fneum]

This will be useful! But I think the setting should be integrated in the existing setting:

transmission_limit: vopt

or

transmission_limit:
    2025: v1.05
    2030: v1.1
    2035: v1.15
    2040: v1.2
    2045: v1.25
    2050: v1.3

This follows how we do this elsewhere.

[martacki]

I guess, I was thinking the same but ultimately the change you're suggesting would create somewhat redundant code. The base_year automatically uses the transmission_limit set in the config; just the default setting of vopt is somewhat not optimal. It would be better to have v1.05 or alike. If TYNDP expansion is active probably v1.0 would be best.

But this is generally true, if not optimizing in 5 year increments but 10 year increments, I'd also use v1.1 rather than v1.05. (Otherwise the model only has 5% increase limit for 10 years)... I guess there's no perfect way to do this?

Anyway if we want to overwrite it also for the base_year, the same fragment is needed in add_baseyear.py.

Pls let me know what you think - not only for this, but also maybe an idea how to handle the default setting depending on how the planning_horizon increments are set?

[martacki]

just checked again - main requirement would be either adding a planning_horizon to prepare_network, or adding another parameter elec: to the keys of transmission_limit.

Increasing the limit is not necessary as the new limit is now always calculated from s_nom_opt + p_nom_opt from the previous horizons, so keeping it at v1.05 is better. We could ofc calculate it always from p_nom, not p_nom_opt, then your suggestion makes sense (better to resolve the issue from my previous comment, worse in case the previous horizon didn't optimise transmission much , in which case there might be a bit of excessive build-out later which I guess is rather unlikely)

[fneum]

but also maybe an idea how to handle the default setting depending on how the planning_horizon increments are set?

I think this should be left to the user. I would not automatically infer this.

just the default setting of vopt is somewhat not optimal. It would be better to have v1.05 or alike.

I would stick with vopt as default because this is the current state. Users can just adjust.

just checked again - main requirement would be either adding a planning_horizon to prepare_network, or adding another parameter elec: to the keys of transmission_limit.

I think the solution will come with @FabianHofmann's #1838. So this PR should be merged afterwards and this is no concern anymore.

Increasing the limit is not necessary as the new limit is now always calculated from s_nom_opt + p_nom_opt from the previous horizons, so keeping it at v1.05 is better.

Ok, agreed. Then the limit is always relative to the volume in the previous horizon, not relative to the capacities in the base year. That is fine. The indexing by planning horizon makes sense nevertheless as build-out could be configured to increase.

transmission_limit:
    2025: v1.05
    2030: v1.05
    2035: v1.05
    2040: v1.1
    2045: v1.1
    2050: v1.1

Does that sound good?