Network Reductions and Results Reporting

[luke-kiernan]

How should we be reporting flows when they overlap with network reductions? The current de-facto standard seems to be:

• parallel: the combined branch is one thing, name like foo_double_circuit, and then we report the total under that.
• series: for each individual piece, report the combined flow as the flow for that branch. This matches the physics for lossless network models.

@m-bossart correct me if I'm wrong.

However, once we run into nested stuff, things get weird. Suppose we have two degree two chains in parallel: how should that be reported?

[m-bossart]

I just discussed this with @jd-lara. The conclusion is it becomes too messy with the nested reductions to maintain the current design of results reporting. It is time to refactor so that all branch reporting is by individual branch only. This means changing the current practice of reporting the _double_circuit flow the optimization variable, and instead post-processing individual flows for each branch when writing the output. This will also be an improvement for AC formulations. In the current status, we report the two-port equivalent flow for all segments of a series chain, even though they are not exact. With the new refactor, we should post-process based on the reduction object and report the correct flows per branch.

The machinery for computing branch flows from reduction objects lives in PNM and is used in POM and PF. The good news is we probably have almost everything we need in the network reduction data and the existing maps, we just need to write new methods for writing the output.

@luke-kiernan It also might make sense to switch over to arc based indexing on the optimization container to match the matrices as part of this effort.