Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt equity constraint to sector-coupled networks #659

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

koen-vg
Copy link
Contributor

@koen-vg koen-vg commented May 8, 2023

This pull requests updates the equity constraint to include all energy carriers in sector-coupled models. For details on how this is done and which modelling and implementation choices were made, see the docstring and comments in the relevant function.

For example, here are two networks solved with a 30% and 95% country-level equity constraint, respectively:
Skjermbilde fra 2023-05-08 17-34-05
Skjermbilde fra 2023-05-08 17-34-09
Note the significant shift of solar investment to Germany, the Netherlands and Belgium in the higher equity network (the lower picture), as well as some smaller regional differences (e.g. Finland/Estonia). (However, these results were produced with a weekly time resolution in order to test quickly, so don't take them too seriously!)

From my testing, the constraint starts to have a significant effect from an equity level of around 70-80%. All in all the results seem reasonable and I think having some level of equity can even be a good "default" or "baseline" for most modelling.

Unfortunately, since there are so many different components in the sector-coupled network, the implementation is on the long side, and I don't think it can be made much smaller. There is also potential for bugs or leaks where some new component is added in future versions and it's forgotten to take it into account in the equity constraint. Even for the current implementation, I tried quite hard to make sure that I caught everything but it would be great if something else could also have a look through it just to have a second pair of eyes.

Maybe it would also be an idea to add an automated test to make sure that this implementation at least keeps running? Checking that the constraint actually works is unfortunately quite a bit of work; about as much as writing the constraint in the first place in fact. But it would also be useful to write a post-processing step which calculates equity levels after the fact and checks that they are within bounds.

I think the only obvious problems with the current implementation are:

  • Tested for electricity-only and sector coupled networks, but only for overnight foresight. (But the original implementation was also only for overnight foresight.)
  • Gas production (e.g. in the North Sea) is counted as imported since implementation-wise this is lumped together with pipeline and LNG imports. Too bad for Norway, the Netherlands and the UK: all their locally produced gas is not counted towards energy equity. Fixing this would require some changes "upstream" in the workflow.

I would document this better in the wildcards documentation, but whole sector-coupled network wildcards section of the documentation seems to be under construction. Anyway it's not so clear how to document options that can appear both in {opts} and {sector_opts} (such as EQ) but might have slightly different behaviour in the different cases.

Checklist

  • I tested my contribution locally and it seems to work fine.
  • Code and workflow changes are sufficiently documented.
  • Changed dependencies are added to envs/environment.yaml.
  • Changes in configuration options are added in all of config.default.yaml.
  • Changes in configuration options are also documented in doc/configtables/*.csv.
  • A release note doc/release_notes.rst is added.

@koen-vg koen-vg mentioned this pull request Jun 16, 2023
6 tasks
@koen-vg
Copy link
Contributor Author

koen-vg commented Dec 22, 2023

Hi! Any updates on when this might be merged, or what might need to be done in order to get it merged? Do you need me to write tests first?

@koen-vg
Copy link
Contributor Author

koen-vg commented May 24, 2024

Maybe after I resolve the merge conflicts, this could also be a candidate for v0.12, @fneum? I can do the necessary work to document this a little bit better and also add a configuration option to make this compatible with the new way of handling wildcards, scenarios etc. I still believe this is a valuable feature even if a bit complex; potential caveats will be documented.

@fneum fneum added this to the v0.12.0 milestone May 24, 2024
@fneum fneum modified the milestones: v0.12.0, v0.13.0 Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants