Currency year update / alternative handling

[koen-vg]

First of all, we currently use 2020 euros, but inflation since then has been about 20%; ample reason in my view to update technology-data to 2023 euros or possibly wait until the new year and go with 2024 euros. 20% is a lot!

But I think pypsa-eur could also benefit from communicating the currency year more transparently. For new users, there is nothing about this in the documentation, and you have to know to look at the configuration file in the technology-data repository in order to figure out that we use 2020 euros. In order to switch to 2023 euros, you have to clone technology-data, re-run it and point pypsa-eur to your own branch.

In an ideal world, I think it would be great if we had a currency_year: <yyyy> option in the pypsa-eur configuration under the costs section. Maybe it would be possible to include technology-data as a git submodule and a snakemake module so that technology-data runs automatically as part of the pypsa-eur workflow.

If there is any interest in this, I think it wouldn't be too much work and I'd be happy to have a go at it. But only if others think it's worth implementing. At a bare minimum, I would add mention of the currency year under the "Techno-Economic Assumptions" section of the documentation, as well as the documentation of the costs section of the configuration.

[lkstrp]

Maybe it would be possible to include technology-data as a git submodule and a snakemake module so that technology-data runs automatically as part of the pypsa-eur workflow.

Since a while there is on my list to move technology-data to the same pip/ conda structure similar to powerplantmatching. I think that is a better approach than adding a submodule to pypsa-eur. Do you have anything against this approach? currency_year we can implement in any case.

[koen-vg]

Ah, so the point would be to make technology-data a package which would be imported and used to generate the required costs_yyyy.csv files on demand instead of downloading the .csvs from github directly as is done now? That sounds like a very good solution to me, then it would also be very easy to configure different currency years, etc. Happy to wait for that. Maintaining a git submodule would have a comparatively high overhead.