Condensed & clarified min up & downtime constraints. (possible bug fix)

[josiahjohnston]

Moved this feature out of pull request #96.

Matthias's last response was:

I am concerned that you dropped the idea of having a band of capacity that does not participate in the minimum downtime constraint (previously calculated as committable_fraction). 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.

I drew some figures to make sure we all have a similar understanding. This one has a breakdown of how installed capacity gets whittled down to committable capacity.

This one is a time series of committable capacity in prior timepoints.

I don't understand why committable capacity in prior timepoints should impact committable capacity in the timepoint being considered. I expect the formula to be committed_capacity[t] <= commitable_capacity[t] - sum(recently_shutdown_cap[t_prior] for t_prior in window), where the number of timepoints window is determined by the magnitude of minimum downtime. If a prior timepoint had higher committable capacity, that shouldn't increase the headroom in the target timepoint t. Your earlier equation was effectively using max(commitable_capacity[t_prior] for t_prior in window) which didn't make sense to me. Are you worried about a capacity that has a scheduled maintenance outage in the target timepoint getting mixed up with capacity that was recently shut down? I don't see how that would be a problem since a generation project's capacity should be roughly interchangeable, and you could legitimately schedule to shutdown a generation unit just before maintenance is going to begin so that maintenance overlaps with minimum downtime.

[josiahjohnston]

I merged the code readability improvements into commit 3921704. The actual bug fix is a trivial change, and I'll open a separate issue for that discussion.