Split `planning_horizons` wildcard into investment year and cost year

[fneum]

We often model 2050 with 2030 cost assumptions in overnight scenarios.

It would be consistent to separate the planning_horizons wildcard into two wildcards investment_year and cost_year. For myopic optimisation, these should be identical.

[ebbekyhl]

Hi Fabian @fneum,

Just some thoughts on this issue. I see that this is a fairly old issue, but since it has not been resolved yet, I try to go for it.

Would you suggest a similar approach to what was done in the multiyear-branch of pypsa-eur, i.e. making weather year a wildcard (https://github.com/PyPSA/pypsa-eur/tree/multiyear)? Furthermore, have you considered integrating weather year as a wildcard with what you propose in this issue? A weather year wildcard would ofc imply a change in the pypsa-eur framework as well.

In this case, we would obtain postnetworks named: 'elec_s{simpl}_{clusters}_lv{lv}_{opts}_{sector_opts}_iy{investment_year}_cy{cost_year}_wy{weather_year}.nc'

With letters infront of wildcards to avoid ambiguity. Or does it get too messy with that many year-wildcards?

[fneum]

Hi @ebbekyhl, sounds good in general with the prefixed and wildcards. @lisazeyen also has put some thought into it, so maybe quickly check in with her. I'd keep the weather year out of it for the moment. The wildcard would need to be placed rather at the beginning as it affects PyPSA-Eur already: elec{weather_year}_s{simpl}......

[martavp]

Hi both. We in Aarhus are particularly interested in including the {weather_year} but it makes sense to design a naming structure that is compatible with having 3 years in the name (weather, planning_horizon and cost) without getting too messy.

[lisazeyen]

Hi @ebbekyhl , I also like the idea and we were thinking about it before. I agree with @fneum that it would be nice to move the wildcard for the weather year at the beginning of the name (elec{weather_year}_s{simpl}.....). I think for most people weather year and planning horizon are the more important parameters. One could think about having those two as a wild card and specifying the cost year only in the config.yaml here. Then the desired behaviour would be for an overnight/single year optimisation to take the cost year from the config.yaml. In case of a multi-year optimisation take the cost assumptions of the investment year. Thereby one could avoid having super long names with 3 years. What are your thoughts @martavp @fneum ?

[fneum]

Weather Year

Yes, so the reason why elec{weather_year}_s{simpl}..... needs to go in the front is that it affects all network files from the add_electricity rule.

The {weather_year} wildcard should also be an optional wildcard; i.e. it can stay empty in which case the settings from the config.yaml will be used. The config.yaml allows more nuanced time frames, e.g. July-June weather years.

If you want, I'll update the WIP PRs in PyPSA-Eur(-Sec) for multiple weather years so it's more or less compatible with the current version and you could continue from there? Also feel free to continue these yourselves.

https://github.com/PyPSA/pypsa-eur/pull/204

https://github.com/PyPSA/pypsa-eur-sec/pull/75

Investment and Cost Year

Whether {cost_year} should be a wildcard depends on what simulations you'd like to run. I think I'd follow @lisazeyen's suggestion unless you want to sweep across cost assumptions and do not want to do it carrier-specific in the {sector_opts} wildcard with onwind+p0.5.

elec{weather_year}_s{simpl}_{clusters}_lv{lv}_{opts}_{sector_opts}_iy{investment_year}.nc

[fneum]

also tagging @koen-vg who I know has been working on getting multiple weather years to run in PyPSA-Eur

[martavp]

Thanks, @fneum and yes, I'm also fine with @lisazeyen's suggestion, this will make the network names less messy

[koen-vg]

This is maybe more relevant to PyPSA-Eur and https://github.com/PyPSA/pypsa-eur/pull/315, but since discussion seems to be happening in a few different places I'll just comment here.

I think it would be great to be able to sweep multiple weather years using a wildcard! There are, however, some things to keep in mind.

A different but very related issue is that of running PyPSA-Eur over a single multi-year period, for example doing a single greenfield optimisation over the period 2010-2020. (In the case of multiple investment periods, one could imagine running the model for a few years in each investment period, but that use-case maybe less pressing.) Anyway, if multi-year periods are to be supported, how would that interact with a {weather_year} wildcard?

What I have worked on is an implementation where we have a {year} wildcard which is allowed to be either a single year ("2020") or a range of years ("2010-2020"). In this case, we found it most natural to define the snapshots of the network over this range. One unfortunate side-effect is that the base network is then already different for different modelling periods, since that's where the snapshots are set. In order to avoid building different bus regions, etc. for different base networks, we worked around this by defining a separate "constant" base network. This is probably not the most elegant solution; another possibility might be to redefine the network snapshots in the add_electricity rule.

Setting the network snapshots to different year ranges might also make it easier to work with e.g. load data from different years in the future.

I don't think there are any very easy answers here, as it seems inherently a bit complicated to mix weather, load and cost data all from different years.

[ebbekyhl]

For the OP, this issue is addressed here #263. I did not touch weather year since this seems to be developing well elsewhere.