Enforce non-increasing shutdown power constraint across horizon boundary

[sriharid]

Enforce the non-increasing shutdown power constraint in between the previous timepoint and the current timepoint, instead of the current and the next timepoint. This will ensure that the constraint is enforced across horizon boundaries as well.

Fixes #1003

[sriharid]

Hold this PR. Investigating run-time issues.

[anamileva]

I still don't understand this. Horizons are independent by design. It looks like a bunch of tests are failing, so this will require careful consideration of interactions.

[sriharid]

There was a bug in the previous patch which was causing the failed tests. This bug has been fixed now.

A couple of points:

• The main issue this patch attempts to fix is the fact that units that are not in the committed state could have spurious generation, i.e., shutdown_power (<= pmin) starting from the first timepoint of a horizon
• The main difference between this implementation and the previous one is: the constraint is enforced between t-1 and t instead of t and t+1. Thus the corner case at the horizon boundary is handled.
• While horizons are independent, there are other constraints that are enforced across linked horizons
• This fix is similar to the implementation in increasing_startup_power_by_st_constraint_rule() where too linked params are used

Please check the current fix. We are testing this fix. Will write back once we look at the results.

[sriharid]

@anamileva, just to clarify, this fix is meant for fixing "phantom" generation that could happen due to decreasing_shutdown_power_constraint_rule not enforcing the shutdown power constraint between the first timepoint of a horizon and the last timepoint of the previous horizon.

The fix has been tested to confirm that:

• the issue described above is seen at least once without the fix, and
• the issue is not seen at all with the fix in place.

Can provide further info the test we performed and the checks we made.

[anamileva]

Ah ok, this makes sense for linked horizons. Thanks, @sriharid!