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

Split out time aggregation to its own rule #1065

Merged
merged 2 commits into from
May 20, 2024

Conversation

koen-vg
Copy link
Contributor

@koen-vg koen-vg commented May 15, 2024

As noted, build year aggregation as in #1056 doesn't work as implemented when combined with time series segmentation because the segmentation could (and often is) different for different planning horizons.

Changes proposed in this Pull Request

The present PR splits time aggregation off into its own rule which is run only once for all planning horizons. This rule is what constructs the new subset of snapshots and their weights; the aggregation of time-dependent data is performed in prepare_sector_network.py

I thought this isn't a terrible thing even independently of build year aggregation; there might be other times when you want to directly compare the same network at different planning horizons snapshot-to-snapshot. I also imagine it might be a little easier to implement new time aggregation features as this step is now a little more isolated and easier to comprehend.

Do let me know if this seems like a reasonable idea or not, or if anyone could imagine a different but better way of achieving the same objective.

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.

@fneum fneum added this to the v0.11.0 milestone May 19, 2024
Copy link
Member

@fneum fneum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent! This is a very good idea! I tested it with a few cases not covered in the regular tests and it works well.

@fneum fneum merged commit 9527f4c into PyPSA:master May 20, 2024
6 checks passed
@fneum fneum mentioned this pull request May 23, 2024
6 tasks
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