Unit commitment smaller problem

[josiahjohnston]

A variety of optional tweaks to reduce the problem size. The default behaviors remain the same as before. In one benchmark, these tweaks reduced the number of variables & constraints by about 66% each.

• Optionally define spinning reserves as expressions rather than decision variables
• Set part-rate fuel use requirements to an equality (instead of an inequality) when only one line segment is provided
• Provide an option to skip tracking unit commitment startup & shutdown.

[bmaluenda]

These look good, though I have a question: Is there any downside to defining spinning reserves as expressions? Why do it optionally and don't just make it the default behavior?

[josiahjohnston]

Expressions might be a better default behavior, but that is a larger discussion and depends on people's use cases. My motivations for this pull request were:

1. Being conservative about backwards compatibility of behaviors (trying to maximize chances of consensus)
2. Using variables enables taking on lower values to reduce project-level contigencies, especially when discrete unit commitment is enabled, and committed capacity may exceed the amount of capacity that is strictly needed.
3. Also opens up the possibility of further customizations like adding variable costs for spinning reserve provision. (low likely-hood)

[mfripp]

Could we automate this?

• Do startup/shutdown calculations if and only if minimum uptime, minimum downtime, startup fuel or startup O&M are specified; otherwise these calculations can be omitted (probably done with sparse sets)
• I see you already use the simpler fuel use calculation automatically when there is only a single fuel; does this make a difference in model size or speed?
• At one point we planned to deprecate spinning_reserves in favor of spinning_reserves_advanced. But maybe we should just lock in these simplifications, or go further and use the up/down slack directly. Then we could rename it spinning_reserves_simple and keep it in the codebase. It would be interesting to see if this is much smaller/faster than the simplest implementation with spinning_reserves_advanced.