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
When multiple startup types are defined, unique_startup_type_constraint_rule() ensures that not more than one of the GenCommitBin_Startup_Type flags is 1 at any point by equating their sum to the binary flag GenCommitBin_Startup. However, there is no such constraint on the power provided by each of the startup types, i.e., GenCommitBin_Provide_Power_Startup_By_ST_MW. This is okay as long as the unit gets committed within the same subproblem in which the start up trajectory begins, in which case the increasing_startup_power_by_st_constraint_rule() ensures that power provided by exactly one startup type becomes positive. However, when the commitment happens in a subsequent subproblem, positive power could be provided for multiple startup types, which then results in an infeasibility at the time of commitment, since the overall startup power (which is the sum of the individual startup powers) needs to be set to 0 at the time of commitment, but that cannot be possible since the startup power can be set to 0 only for that startup type whose GenCommitBin_Startup_Type is set.
Note: Commitment could be forced minimum_up_time hours before the unit becomes unavailable, so this could be a trigger for the infeasibility.
The text was updated successfully, but these errors were encountered:
When multiple startup types are defined,
unique_startup_type_constraint_rule()
ensures that not more than one of theGenCommitBin_Startup_Type
flags is 1 at any point by equating their sum to the binary flagGenCommitBin_Startup
. However, there is no such constraint on the power provided by each of the startup types, i.e.,GenCommitBin_Provide_Power_Startup_By_ST_MW
. This is okay as long as the unit gets committed within the same subproblem in which the start up trajectory begins, in which case theincreasing_startup_power_by_st_constraint_rule()
ensures that power provided by exactly one startup type becomes positive. However, when the commitment happens in a subsequent subproblem, positive power could be provided for multiple startup types, which then results in an infeasibility at the time of commitment, since the overall startup power (which is the sum of the individual startup powers) needs to be set to 0 at the time of commitment, but that cannot be possible since the startup power can be set to 0 only for that startup type whoseGenCommitBin_Startup_Type
is set.Note: Commitment could be forced minimum_up_time hours before the unit becomes unavailable, so this could be a trigger for the infeasibility.
The text was updated successfully, but these errors were encountered: