You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is 1:1 pasted from the discussion opened by @sstroemer in #646 so we can track this issue:
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.
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
The text was updated successfully, but these errors were encountered:
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.
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.
What happened?
This is 1:1 pasted from the discussion opened by @sstroemer in #646 so we can track this issue:
storage_initial
defaults to0
, whilecyclic_storage
defaults totrue
. This may not be the expected/intended behavior ofcyclic_storage
? Compare: "For instance, withcyclic_storage: true
and astorage_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.storage_initial
seems to be hard: Settingnull
does not seem to work, and_REPLACE_
is not valid in thetech
specification. I know it could be done from code, but what is the preferred way to do that in the YAML?Which operating systems have you used?
Version
v0.7
Relevant log output
No response
The text was updated successfully, but these errors were encountered: