DSS V and Y manipulation in inputs

[zzink731]

Initial manipulation of V and Y coming from DSS to be properly used in LPF.

[NLaws]

@zzink731 thanks for making a PR! However, I am deprecating this package. I just updated the README.md to reflect this, and point to where the new fixed point linear model will live - BusInjectionModel.jl. Easiest thing for you would be to just work in your fork of LinearPowerFlow.jl I'm guessing. But happy to discuss getting BusInjectionModel.jl up to speed too.

[NLaws]

@zzink731 also worth mentioning that many of the things that you might want to do using OpenDSS are already done in the CommonOPF.jl package here. More specifically, here is where the system admittance matrix is taken from an OpenDSS model (the source impedance is not used so the code does not turn off sources).

[zzink731]

@NLaws Hey, No problem! And understood. I have written up what I need for my purposes in my own Python incarnation with 3phs and delta conns. So my plan was going to be to gradually port this over to into LPF.jl. If that's ultimately not that productive though, I can do this directly in BIM.jl. My general outline would be building a test and expanding from single phase wye. Let me know if that sounds good.

[nlaws-camus]

Hey @zzink731 FYI I found another issue with extracting the impedance matrix from OpenDSS for OPF: OpenDSS will change the load models from constant power (model=1) if the solution voltages go outside of the vminpu/vmaxpu (Load attributes) and thus modify the Y matrix (account for loads in Y). I wrote a method to confirm that the loads are the same in the solution as were set in the Load models here. You can prevent OpenDSS from changing the load model by expanding the vminpu/vmaxpu values for all Loads, and probably need to increase MaxIter as well (default is 15 I believe). This will slow down the solve time (OpenDSS developers decided to change the load models while solving to speed things up).

[zzink731]

@NLaws Thanks for the heads up on this! I found power mismatches and expanding vminpu/vmaxpu resolved any remaining discrepancy between OpenDSS and the complex LPF equation.

On a different note, I noticed that you included a time index in the model. I see an alternative where a separate model is created and solved for each time step which I imagine is computationally less intensive than one big model. Any thoughts on this?

[NLaws]

if there are no time-coupling constraints then there is no reason not to solve each time step independently. the most common example of time-coupling constraints is energy storage.

[zzink731]

Hi @NLaws, Is your plan to replicate the values held in the Inputs struct used in LPF in the Network struct from CommonOPF?

[NLaws]

Is your plan to replicate the values held in the Inputs struct used in LPF in the Network struct from CommonOPF?

Yes (for the most part, and the Network struct is relatively complete). The limit values for constraints are a work-in-progress, but some are in a new struct called VariableBounds.. However, there is no admittance matrix in the Network struct because all the other models use edge impedances, which are obtained via CommonOPF.zij(i, j, network) or the like. The admittance matrix for the LPF model (which I've started to port here) is lacking. I suppose that one could add a method that takes in the Network and outputs Y and the node order. Maybe by iterating over the Network.graph's edges via a breadth first search.

[zzink731]

Ok got it, recreating the Y matrix in that manner seems doable although a tad bit more involved for multiphase.

vref (and more trivially Sbase) is also not gathered by dss_to_Network to then be available to LPF. It would follow the theme of limiting dss interaction to this method to include it here but similar to Y, vref will likely only be used by LPF.