Support alternative slack definitions

[jeanpaulwatson]

When including feasibility slacks, we should provide two options: (1) The existing option, which is strictly intended to model load shed and over-gen associated with a given bus (consequently, e.g., there is no over-gen if there is no generation at the bus) - and - (2) A new option that allows for "power balance" slack - all buses, independent of type. Useful for certain types of feasibility diagnostics, or at least we think so.

And given the two types, one should require the user to carefully pick which option - so they are making a conscious and intentional choice regarding the slack variables they are injecting.

[bknueven]

The 2nd type is equivalent to just putting slack at the reference bus, which is more in line with typical practice.

[michaelbynum]

@bknueven I think that would be true if there were not any thermal limits. Is it true with thermal limits?

[bknueven]

My comment is slightly off -- I was misinterpreting what JP said.

Another type of slack commonly used is what I suggest -- relax power balance at the reference bus, and (often) relax the thermal limits as well. This slack formulation works better with PTDF (and PTDF-like) approximations of power flow because it allows for fewer non-zeros in those dense transmission constraint rows.

I think ideally we'd support all three.

[michaelbynum]

Sounds good to me.