Skip to content

Min/max generation for Generators#1047

Merged
lkstrp merged 14 commits intoPyPSA:masterfrom
cpschau:generator_constraint
Oct 1, 2024
Merged

Min/max generation for Generators#1047
lkstrp merged 14 commits intoPyPSA:masterfrom
cpschau:generator_constraint

Conversation

@cpschau
Copy link
Copy Markdown
Contributor

@cpschau cpschau commented Sep 25, 2024

Changes proposed in this Pull Request

This PR introduces two new optional fields for generators, namely e_sum_min and e_sum_max. These fields restrict the overall amount of energy generated by the unit during a single optimization horizon within the constraint define_generators_constraints. Here, e_sum_min serves as the lower bound for generation, and e_sum_max as the upper bound.

The extension offers the following practical advantages:

  1. The use of certain carriers in the system can be enforced via e_sum_min, such as imports of natural gas or the consumption of unsustainable biomass.
  2. The finiteness of certain resources, such as biomass or CO2 sequestration, can be efficiently represented via the e_sum_max.

In comparison to the current modeling approaches using store and link components, it requires 1. fewer components, thereby increasing the sparsity of networks (1 generator vs. 1 store + 1 link), and 2. reduces the complexity of the linear program (LP) by eliminating the need for storage-consistency constraints.

Checklist

  • Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
  • Unit tests for new features were added (if applicable).
  • A note for the release notes doc/release_notes.rst of the upcoming release is included.
  • I consent to the release of this PR's code under the MIT license.

@cpschau cpschau changed the title Minimum generation for Generators Min/max generation for Generators Sep 26, 2024
@cpschau cpschau requested a review from fneum September 26, 2024 15:37
lkstrp and others added 4 commits September 27, 2024 14:07
* refactor: naming convention `network` -> `n`

* refactor: naming `sub_network` and `sub-network`

* refactor: naming `df` -> `static`

* refactor: naming `dataframe` -> `df`

* refactor: naming `pnl` -> `dynamic`

* ignore linopy in type checking

* docs: add release notes

* fix: pre-commit

* make dataclasses more robust

* fix: missed pnl

* fix docs

* add some more deprecation decorators

* fix type ignore
* add 4 kA high-temperature low-sag (HTLS) line type

Based on data from JAO Static Grid Model.

* Updated description in the user-guide: components.rst.

---------

Co-authored-by: bobbyxng <[email protected]>
@cpschau cpschau marked this pull request as ready for review September 27, 2024 12:12
@cpschau cpschau requested a review from lkstrp September 27, 2024 12:13
Copy link
Copy Markdown
Member

@lkstrp lkstrp left a comment

Choose a reason for hiding this comment

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

Some small stuff and I check for another test with snapshots

Copy link
Copy Markdown
Member

@lkstrp lkstrp left a comment

Choose a reason for hiding this comment

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

needs double check with test

Copy link
Copy Markdown
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.

Great!

@lkstrp lkstrp merged commit 56135c0 into PyPSA:master Oct 1, 2024
@PriyeshGosai
Copy link
Copy Markdown
Contributor

Is it possible to include this function to links?

@lkstrp
Copy link
Copy Markdown
Member

lkstrp commented Oct 14, 2024

At least not planned in a similar approach. What is your use case for this?
A link is not a source, but must be linked to generators/stores and therefore does not justify the component extension with another attribute enough. Also, the implementation here is too specific for it to be extended nicely for other components at the moment.

@FabianHofmann
Copy link
Copy Markdown
Contributor

I think generalizing it would be helpful. Often total transmission of individual links or total energy consumed/produced by conversion technologies such as electrolyzers need to be fixed per optimization horizon. The only question is whether the constraint should run on p0 or p1, where I would strongly lean towards p0.

A side note: I don't like the current naming of the constraint as it is very unspecific. When generalizing, i would prefer something like "define_total_production_constraint"

@PriyeshGosai
Copy link
Copy Markdown
Contributor

@lkstrp I see that @FabianHofmann addressed the need for the generalization of this constraint. I agree with the use cases. I also agree we should set the constraint at p0.

@SunnyBlueWhite
Copy link
Copy Markdown

e_sum_max is a fixed value, how should I make it vary with the installed capacity?

@fneum
Copy link
Copy Markdown
Member

fneum commented Feb 17, 2025

e_sum_max is a fixed value, how should I make it vary with the installed capacity?

This feature is not implemented.

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.

7 participants