This is an update of the stale pull request #97 . Either this is a bug that needs to be fixed, or a confusing modeling formulation that needs clarification in documentation and/or formulation.
The minimum downtime constraint is currently:
CommitGen[t] <= max(CommitUpperLimit[t_prior] for t_prior in time_window + 1) - sum(m.ShutdownGenCapacity[t_prior] for t_prior in time_window)
I think it needs to be:
CommitGen[t] <= CommitUpperLimit[t] - sum(m.ShutdownGenCapacity[t_prior] for t_prior in time_window)
Matthias has stated using max() is necessary to track a band of capacity that needs to stay down for maintenance. To me, it looks like it will be overestimating available capacity if more capacity was available in prior timepoints.
Matthias's comments from prior documentation & a post May 19, 2017 on Pull Request #96. The max(...) term finds the largest fraction of capacity that could have been committed in the last x hours, including the current hour. We assume that everything above this band must remain turned off (e.g., on maintenance outage). Note: this band extends one step prior to the first relevant shutdown, since that capacity could have been online in the prior step.
... This implements a band of capacity that does not participate in the minimum downtime constraint. Without that term, the model can turn off some capacity, and then get around the min-downtime rule by turning on other capacity which is actually forced off by gen_max_commit_fraction, e.g., due to a maintenance outage.
My response: Any forced maintenance outage encoded by gen_max_commit_fraction will be directly reflected into ShutdownGenCapacity and subject to minimum downtime, if that capacity was online when the maintenance event started. If sufficient capacity was offline prior to maintenance, then min downtime would not need to be tracked separately. I don't see a separate band of capacity that needs to be implicitly tracked. The way I read it, the max(...) term would overestimate available capacity if prior timepoints in the window had more capacity available. I think the max(...) term needs to be replaced by m.CommitUpperLimit[g, t].
This is an update of the stale pull request #97 . Either this is a bug that needs to be fixed, or a confusing modeling formulation that needs clarification in documentation and/or formulation.
The minimum downtime constraint is currently:
CommitGen[t] <= max(CommitUpperLimit[t_prior] for t_prior in time_window + 1) - sum(m.ShutdownGenCapacity[t_prior] for t_prior in time_window)I think it needs to be:
CommitGen[t] <= CommitUpperLimit[t] - sum(m.ShutdownGenCapacity[t_prior] for t_prior in time_window)Matthias has stated using max() is necessary to track a band of capacity that needs to stay down for maintenance. To me, it looks like it will be overestimating available capacity if more capacity was available in prior timepoints.
Matthias's comments from prior documentation & a post May 19, 2017 on Pull Request #96. The max(...) term finds the largest fraction of capacity that could have been committed in the last x hours, including the current hour. We assume that everything above this band must remain turned off (e.g., on maintenance outage). Note: this band extends one step prior to the first relevant shutdown, since that capacity could have been online in the prior step. ... This implements a band of capacity that does not participate in the minimum downtime constraint. Without that term, the model can turn off some capacity, and then get around the min-downtime rule by turning on other capacity which is actually forced off by gen_max_commit_fraction, e.g., due to a maintenance outage.
My response: Any forced maintenance outage encoded by gen_max_commit_fraction will be directly reflected into ShutdownGenCapacity and subject to minimum downtime, if that capacity was online when the maintenance event started. If sufficient capacity was offline prior to maintenance, then min downtime would not need to be tracked separately. I don't see a separate band of capacity that needs to be implicitly tracked. The way I read it, the max(...) term would overestimate available capacity if prior timepoints in the window had more capacity available. I think the max(...) term needs to be replaced by m.CommitUpperLimit[g, t].