PNM interface changes

[luke-kiernan]

Fix things for PNM interface changes. The exporter tests error--the newly added winding_group_number fields don't match--but I'll leave that for @rbolgaryn to fix. Otherwise, things are back to where they were a week ago: 20-30 test failures, all due to low-priority issues (reactive power distribution, issue #201).

edit: I also moved the loss factor and distributed slack tests into their own files. If vanilla power flows aren't working, those tests bury those errors behind a wall of similar messages. I don't use failfast because it stops the whole testing process, not just the current test set.

[rbolgaryn]

Looks good!

[GabrielKS]

nice thanks for updating

[m-bossart]

This returns a list of arc tuples, not the branches names so the function name and comment should be updated

[luke-kiernan]

Fixed. @jose I know you've said that branch_lookup should have strings as keys, not tuples. I'll fix that in a separate PR: get things working first, then make design changes.

[jd-lara]

This should already be available to work it out in what's on PSY5. Please add a proper fix to this in the PR.

[luke-kiernan]

Hmm. PNM's data structures all have tuples as keys, though. How about 2 separate lookups, arc_lookup (keys are tuples) and branch_lookup (keys are strings)? Is that ok? I could make it work with a single lookup with keys as strings, but the side effects would be

1. I can only use the arc/branch-related network reduction data in places where I have access to the PSY.System. I have the names of the branches: the network reduction data requires PSY.Branch objects or tuples.
2. I'd have to name the reduced arcs in such a way that I can retrieve the arc. E.g. as from-to. Otherwise, after figuring out the flows, I have no way of knowing "flow in what?" So I'd be dealing in terms of arcs for the reduced branches anyway, just indirectly.

[jd-lara]

Hmm. PNM's data structures all have tuples as keys, though. How about 2 separate lookups, arc_lookup (keys are tuples) and branch_lookup (keys are strings)? Is that ok? I could make it work with a single lookup with keys as strings, but the side effects would be

1. I can only use the arc/branch-related network reduction data in places where I have access to the PSY.System. I have the names of the branches: the network reduction data requires PSY.Branch objects or tuples.
2. I'd have to name the reduced arcs in such a way that I can retrieve the arc. E.g. as from-to. Otherwise, after figuring out the flows, I have no way of knowing "flow in what?" So I'd be dealing in terms of arcs for the reduced branches anyway, just indirectly.

you need to exploit the NetworkReductionData object in PNM to do this. The map you are talking about is already there.

[luke-kiernan]

The map you are talking about is already there.

I don't follow. Which map do you have in mind?

If branch_lookup has type Dict{String, Int}, that only gives me branch/arc name to index. All the branch-related maps in NetworkReductionData that I see have key type Tuple{Int, Int} or PSY.Branch.

[luke-kiernan]

I've updated the PowerFlowData fields for the fact that everything is indexed by arcs now, not branches. Results are reported by branch name, if the arc corresponds to a system branch (i.e. it's in direct_branch_map); otherwise, I just give it the name {from_bus_no}-{to_bus_no}. I still need to implement reporting the flows in the windings of a 3WT, though.

I temporarily commented out the arc power flow calculations. @m-bossart if you could do the following, then they'll work again:

1. Update the yft, ytf, fb, and tb fields of Ybus so that they take the network reduction into account.
2. Add a get_arc_axis method to Ybus, that returns a Vector{Tuple{Int, Int}} for the arc axis of yft and ytf.

I also adjusted the PowerFlowData constructors for the bus_reduction_map. Now, an AC power flow on a network with a radial or degree 2 reduction runs to completion! I haven't tested for correctness or convergence yet, though.

[luke-kiernan]

I intended for this to be merged after the "Merge branch 'psy5' into lk/psy5-pnm-fixes" commit. That would've brought psy5 of PF in line with psy5 of PNM. When that didn't happen by Tuesday or so, mostly for reasons I don't understand (see the above discussion of branch names vs arcs), I was caught between starting a new branch/PR and continuing to work on the same one. I chose the later. But it sounds like the goal now is to simply get things working again. So I reset locally to that commit (after saving my work to a different branch) and force-pushed the result.

edit: oh, some changes here rely on PR #177 in PNM, which in turn relies on PR #1511 in PSY. So those will need to be merged, too.

[jd-lara]

one minor comment before merge