How should solutions report square voltage variables for parallel lines about powermodels.jl

[frederikgeth]

I'm not going to comment on whether this is an issue or not, but I can comment on why this is. The wr and wi variables are actually shared between different parallel branches, i.e. only one complex lifted variable $V_i V_j^{}$ = wr+jwi exists for each pair of buses that appear in the topology. (more background see https://arxiv.org/pdf/2202.06449.pdf).

[noahrhodes]

Yes, and it isn't unreasonable that a variable is reported in a single place.

It isn't a terrible hassle, but when looking for the voltage variables of a line and they do not exist, there is the extra step of finding the parallel line that does have the variables.

In addition, it means that it is easy to make data mistakes when running PowerModels.update_data!() if it fails to update the voltage variables for the line that does not contain them in the solution dictionary.

I seems like strange behavior and I am wondering if it is intentional.

[ccoffrin]

This was intentional, but I do think there is room to have a debate around if a better convention is possible.

The guiding principle for the solution data is currently to explicitly report all of the variables in the JuMP model. So for example, if you run an AC-OPF model you get values for the flows on the branches because the S_ij variables are in the model. However, if you run an AC-PF model you do not get the branch flows because these variables are not in the model and are instead represented JuMP expressions. Collections of model variables tend to be 1-to-1 with system components, but there are exceptions from time to time.

As @frederikgeth points out, in some of the convex relaxations the lifted variables are shared across multiple branches. So there is not a nice one-to-one mapping between the variables and the network components. In the case of the SOCWR model, under the hood a special dict called buspairs is setup to hold these shared variables.

When it comes to reporting the results in the solution dict the choices I see are,

1. Add buspairs to the solution data, so it is consistent with how PowerModels works internally
2. Add the variables from buspairs to one representative branch in the system (the current implementation for SOCWR)
3. Add the variables from buspairs to all branches in the system

I can see pros/cons for each of these choices. Interestingly, in the case of the SDPWRM models, I was forced to go with option 1, because the SDP models have more variables than branches. So you need to have a separate dict to store them.

I think a bit more debate about possible uses cases / workflows could help us decide if one of these is a better standard for a convention.

@noahrhodes, I am not sure I follow your concern with respect to update_data! the voltage variables in SOCWR are always put in the same representative branch, so this should work correctly within to the same relaxation. I do see how there could be inconsistencies when sharing across different relaxations / formulations. However, this may be unavoidable. Can you elaborate a bit more about the workflow(s) you have in mind?

[noahrhodes]

What I had in mind was passing solution data as initial values between different powerflow type problems and formulations. But you are right that anything re-using W variables would use the same branch/buspair indexes and any V variable formulations would need to be post-processed anyways.