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

Setting storage_initial and cyclic_storage #650

Closed
3 tasks
sjpfenninger opened this issue Aug 7, 2024 · 3 comments
Closed
3 tasks

Setting storage_initial and cyclic_storage #650

sjpfenninger opened this issue Aug 7, 2024 · 3 comments
Assignees
Labels
Milestone

Comments

@sjpfenninger
Copy link
Member

What happened?

This is 1:1 pasted from the discussion opened by @sstroemer in #646 so we can track this issue:

  1. storage_initial defaults to 0, while cyclic_storage defaults to true. This may not be the expected/intended behavior of cyclic_storage? Compare: "For instance, with cyclic_storage: true and a storage_initial: 0, the stored energy must be zero by the end of the time horizon." [src], which would hint at this being something that one has to opt into.
  2. Disabling storage_initial seems to be hard: Setting null does not seem to work, and _REPLACE_ is not valid in the tech specification. I know it could be done from code, but what is the preferred way to do that in the YAML?

Ad 1.: Only reason I think that may not be "expected" is that I assume the main use-case of cyclic storage(s) to mostly likely be the unavailability of reasonable initial levels of seasonal storages. Letting the model "pick" a starting point and forcing it to achieve that at the end of the modeling period makes sense: A storage operator could try and aim for X% of storage at time T, since they know by experience/history that this works in the long-term. The cyclic storage is then just an approximation of that behaviour (without the multi-year history). Defaulting to 0 however completely breaks that, and is especially harsh for any inflow-dependent hydro storages (which will have a high storage level at the start of most modeling periods (01.01.) instead of 0).

Which operating systems have you used?

  • macOS
  • Windows
  • Linux

Version

v0.7

Relevant log output

No response

@brynpickering
Copy link
Member

brynpickering commented Aug 7, 2024

The current implementation works as expected. The default value of a parameter only gets used in the math expression, so if you do not explictily define storage_initial then its value in calliope.Model.inputs will be NaN. Then the set_storage_initial constraint will not be triggered so you'll get cyclic storage with the initial/final step storage being linked and set to whatever is optimal for the model.

@brynpickering
Copy link
Member

When storage_initial is explicitly set by the user and cyclic_storage: true, then set_storage_initial links the final timestep to storage_initial and balance_storage links the first timestep to the final timestep.

When storage_initial is explicitly set by the user and cyclic_storage: false, then set_storage_initial is not triggered and balance_storage sets the initial storage level to storage_initial.

When storage_initial is not explicitly set by the user and cyclic_storage: true, then set_storage_initial is not triggered and balance_storage explicitly links first and final timestep.

@brynpickering
Copy link
Member

Closing as not an issue. If you disagree @sstroemer then please re-open!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants