PowerModels.jl
PowerModels.jl copied to clipboard
lanl-ansi
Add Tree Topology Constraint
Add a constraint to the OTS model such that at least one edge connects to every active bus.
Key steps,
- in
form/ots.jladd bus-wise constraint calledconstraint_connected(pm, i) - in
base/constraint_template.jladd a constraint template forconstraint_connected, which extracts thebus_arcsdata from ref (i.e.ref(pm, nw, :bus_arcs, i)) and pass this on to the parameterized version ofconstraint_connected - in
base/constraint.jladd an implementation of the parameterized version ofconstraint_connected, extract thez_branchvariables using thevarfunction and add the constraintsum(z_branch[l] for (l,i,j) in bus_arcs) >= 1) - run tests and update OTS tests as needed.
CC @FlorianShepherd
Is this a default constraint for OTS? I don't recall seeing this as a required constraint in the literature for OTS and I can think of cases where isolating a bus is fine (for example, a bus has sufficient generation to meet all the load at that bus-I think RTS 96 has some buses like this)
As I recall this is not discussed in most papers, but I do believe it is important in practical solutions. I don’t think you would want to de-energize buses when making topology changes. If you would like two variants of the model One with and one without this constraint I am open to that. I don’t expect this change will make a big difference on most realistic instances.
On Fri, Oct 18, 2019 at 12:04 PM Russell Bent [email protected] wrote:
Is this a default constraint for OTS? I don't recall seeing this as a required constraint in the literature for OTS and I can think of cases where isolating a bus is fine (for example, a bus has sufficient generation to meet all the load at that bus-I think RTS 96 has some buses like this)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lanl-ansi/PowerModels.jl/issues/616?email_source=notifications&email_token=AAIN5KVX247SSOIQSZHEHHLQPH3DZA5CNFSM4JCJ6OL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVLQWI#issuecomment-543864921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIN5KXDJDWMVOQXMEGOUJDQPH3DZANCNFSM4JCJ6OLQ .
Maybe I missed the definition of an active bus, but will this constraint require a bus with generation and load to have an active line?
It will enforce that any non-status 0 bus in the original network is still energized in the OTS solution, independent of if a load is attached or not.
On Fri, Oct 18, 2019 at 12:17 PM Russell Bent [email protected] wrote:
Maybe I missed the definition of an active bus, but will this constraint require a bus with generation and load to have an active line?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lanl-ansi/PowerModels.jl/issues/616?email_source=notifications&email_token=AAIN5KRHCUUBXPHMNMEGURLQPH4STA5CNFSM4JCJ6OL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVMX5A#issuecomment-543869940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIN5KSKF2BK7NYMXB4YSFTQPH4STANCNFSM4JCJ6OLQ .
This is open to discussion if you think the proposal does not make sense.
On Fri, Oct 18, 2019 at 11:29 AM Carleton Coffrin [email protected] wrote:
It will enforce that any non-status 0 bus in the original network is still energized in the OTS solution, independent of if a load is attached or not.
On Fri, Oct 18, 2019 at 12:17 PM Russell Bent [email protected] wrote:
Maybe I missed the definition of an active bus, but will this constraint require a bus with generation and load to have an active line?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lanl-ansi/PowerModels.jl/issues/616?email_source=notifications&email_token=AAIN5KRHCUUBXPHMNMEGURLQPH4STA5CNFSM4JCJ6OL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVMX5A#issuecomment-543869940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIN5KSKF2BK7NYMXB4YSFTQPH4STANCNFSM4JCJ6OLQ .
FWIW, I had this requirement in my OTS work (~10 years old). Though, I may not have adequately described it. Without the connectivity constraint, I occasionally got results with a bunch of connected components.
Sure... the discussion point is this constraint
sum(z_branch[l] for (l,i,j) in bus_arcs) >= 1)
It seems like this constraint should only applied to those buses that have a load or a generator. But not in cases where a bus has both or neither. In the case where a bus has both, the bus can "self energize" without having any lines active. For example, in a network with lots of equivalencing. Similarly, a bus that has neither, you may want to de activate all the lines at the bus for the same reason as a single line. Say you have a network with i ->j and it is economical to turn off i,j. If you had the same network with i -> k -> j, where k has no load or generation, you'd have the same economical benefit for turning off both (i,k) and (k,j), but you wouldn't be allowed to do so. You'd keep one on and have a little bit of extra losses (less economical) floating around because of a dangling resistance...
The logic in my head was roughly as follows. OTS is an operational dispatch problem, in practice it should be at least n-1 secure, but traditionally we have not considered "SCOTS" and instead have done OTS, which allows for isolated buses and de-energizing no-load pass through buses (like your i,j,k example). If we agree that OTS is really a simplified version of SCOTS, then it seems resonable to add the side constraint that the OTS solution should be one connected component (a necessary conditions for n-1). The proposed constraint is a relaxation of "one connected component", seems like a resonable constraint to add to eliminate some obviously non-n-1 secure solutions.
@claytonpbarrows, was this your logic as well?
@FlorianShepherd would you like to put in your two cents as well?
Ok. If that is the case, you could probably also add a constraint of the form sum z_branch >= num_buses - 1
I agree that OTS is a simplification of SCOTS. And, my logic is similar. Except, I think that there are solutions with multiple connected components that can remain n-1 secure (I'm thinking of multiple large connected components, rather than isolated buses). I imposed the constraint under the assumption that creating multiple connected components through OTS was something that wouldn't be tolerated by operators (either due to n-1 concerns, or due to other concerns like stability, or AC issues... though I suspect those are considered here). I'll confess that I never backed up this logic with any actual analysis.
If your goal is a single connected component, ,I think you can enforce this with a psuedo flow with the switch variables you already have. i.e. push n-1 units of flow from an arbitrary node. Then, the sum of incoming/outgoing flow at each node must be -1 and you can only use edges where z_branch = 1.
Wow, that triggered a discussion (overnight). Sorry for the late response, my social life interferes with work one some Friday nights ;)
I came across this issue, since I try to compare some heuristic optimization strategies (for example simple, greedy hill climbing, genetic algorithm, grey wolf..) with the PowerModels optimization. At our institute we mainly look at distribution grids, but also sub-transmission and transmission grids. (In Europe distribution grids are also modelled as balanced 3-phase systems). The constraint for the heuristic optimization is "connect all buses to the specified root bus(es)", which is not exactly equal to the OTS definition in PowerModels.jl. I came across some cases where buses without loads were being disconnected from the slack / PV-buses, which is actually not a problem since I realized that it only disconnects buses without loads.
However, depending on the optimization task, it would be quite useful to have both SCOTS and OTS. In Germany the sub-transmission (110 kV) and transmission (380kV) level must always be n-1 secure, where SCOTS is required. The MV (10-30 kV) and LV level (0.4 kV) grids are open-ring or radial networks. The OTS optimization is quite useful here to find grid states where all buses are connected to at least one primary-substation (the upper level slack bus). We usually use some topology searches for this and the hill climbing algorithm to find valid grid states where no voltage constraints / line loading limits are violated.
Interesting discussion! In this context, an OTS variant with spanning tree constraints would be quite interesting.
Based on this discussion. I think I spoke too soon with the proposal for constraint_connected, so lets scratch that proposal. Instead I propose the following,
- Leave the current OTS formulation as is, as canonical academic formulation (and update the docs remove the note about a single connected component)
- Add a tree topology constraint (the flow-based variant that what Russell proposed), and add an OTS variant (for testing at least) that enforces tree topologies
- For more realistic SCOTS problem formulations, direct users to an SCOPF extension of PowerModels
@FlorianShepherd, does the current implementation suit your needs? Or would you prefer the tree topology variant?
The current OTS implementation is fine for my purpose. I was just confused by the note in the docs about the connected component.
The tree constraint would be a very nice addition imo. This could be quite useful for distribution grids. :+1:
Documentation as been updated and the name of this issue changed to reflect the new scope.