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
Enforce shutdown trajectory when shutdown is initiated at the first timepoint of a subproblem with linked horizons #1111
Comments
@anamileva, if the proposed fix is okay, I can implement and submit a pull request. |
Sounds good to me, thanks @sriharid! |
@anamileva, we tried to fix the issue as described above. However, the fix requires adding a couple of params - PMin and PMax - to linked parameters. Following is the full explanation with the 3 possible scenarios, and what happens in those scenarios in the current implementation and in the proposed implementation. Please let us know if it is okay to add these two linked parameters. Current Formulation:
There are 3 possible cases:
2a. When Commit[CurrTP] = 0:
In the above case, the constraint is actually incorrect since PMax[NextTP] could be different from PMax[CurrTP]. Proposed Formulation
3 possible cases:
Above constraint is what this function is intended to implement.
The constraint will not bind in this case, i.e., it will always hold true (LHS is always <=0 and RHS is always >= 0). 2b. When Commit[PrevTP] = 1:
This constraint is superfluous in this case since this is already enforced by In the above formulation, UpwardsReserves[PrevTP] is redundant, i.e., even if we don't include it in the formulation, there is no material difference to the final constraints. However, we retained it to be consistent with the rest of the constraints. So we need the following values at the previous timepoint: If CurrTP is the first TP of a linked horizon, we need all the above 6 values from linked data. |
@sriharid, yes, I don't see any issue with adding these two to the linked params. Thank you! |
When there are linked horizons, it is possible for a unit that is committed at the last timepoint of a previous subproblem to generate a shutdown event at the very first timepoint of the next subproblem without honouring any shutdown ramp rate (between these two timepoints) - even when such a shutdown ramp rate is specified.
In the worst case, the unit can directly reach zero generation at the at the very first timepoint of the next subproblem - from a committed state at the last timepoint of a previous subproblem.
The suggested fix for this issue is in
power_during_shutdown_constraint_rule()
ingen_commit_unit_common.py
. This constraint is enforced between the current timepoint (i.e. the timepoint with which the function is called) and the next timepoint. This results in the first timepoint of every subproblem to be unconstrained (for this constraint) with respect to the last (non-lookahead) timepoint of the previous subproblem. The solution to this is to apply the constraint between the previous timepoint and the current timepoint instead.The suggested implementation is consistent with that of
decreasing_shutdown_power_constraint_rule()
, which was fixed in #1070.The text was updated successfully, but these errors were encountered: