add PV bus voltage set-point correction

[jd-lara]

This PR addresses a small issue in matpower files that were generated after running run_pf with q-limits enforced. In these cases matpower stores in the bus field the resulting voltage value. When parsing if the bus is a PV bus, the parser stores the voltage from the resulting power which causes the voltage to be enforced at the q limited voltage value.

[codecov]

Codecov Report

Merging #797 (0e12ac2) into master (686c010) will decrease coverage by 0.03%.
The diff coverage is 73.33%.

@@            Coverage Diff             @@
##           master     #797      +/-   ##
==========================================
- Coverage   94.04%   94.00%   -0.04%     
==========================================
  Files          42       42              
  Lines        9800     9813      +13     
==========================================
+ Hits         9216     9225       +9     
- Misses        584      588       +4     

Impacted Files	Coverage Δ
src/io/matpower.jl	92.59% <73.33%> (-0.50%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 686c010...0e12ac2. Read the comment docs.

[ccoffrin]

Thanks @jd-lara, as I understand the issue you are raising here, this is a known issue to me.

My general concern about how MP implements this feature is what happens if two generators are connected to one bus and they have different target voltage values? In my mind this is an infeasible model. In your proposal, one of those generators will be nominated to be the "preferred" set-point. This is why in PM I have adopted to use the bus voltage value for setting the PV voltage value, there can be no ambiguity. A clear and intuitive rule for how to distinguish such ambiguities is not clear to me. So I concluded to generate an warning message if the bus VM value does not match a generator's desired target,

https://github.com/lanl-ansi/PowerModels.jl/blob/master/src/core/data.jl#L1843

And leave it to the user to resolve the ambiguity. Do you have other suggestions on how we might address these edge cases in a way that would be more user friendly for MP users?

[jd-lara]

@ccoffrin I see where you are coming from and I agree that if the set-points are inconsistent that's an input issue. I added a memento error log. I would suggest throwing an Exception instead if there are inconsistencies.

I think it is better to keep the voltage reference from the generators and let the model solve adjust. In cases where the MP data solve induced large deviations in the vm values then it wouldn't be possible to match results between MP and PM. We have observed this when solving power flow with calculate_pf.

[claytonpbarrows]

@ccoffrin I can see the infeasible case argument where multiple generators with disparate voltage settings are connected to the same bus. But, simple disagreement between the voltage setting in the bus table vs. the gen voltage setting just seems like a shortcoming of the data format - and since the voltage is actually being controlled by the generator, we should use that.
Disagreement between generators at the same bus begs the question of what to do about it...
It appears as though MP does some averaging between the generator voltage settings for all generators connected to a bus (in this line). I don't know if I think it makes more sense to do that or arbitrarily select one of the generator voltage settings. Or, as @jd-lara suggests, throw an exception.

[ccoffrin]

I am open to making a change to address this in the next breaking release, it would be a fairly substantial one.

This is what I am thinking:

• PF methods will use generator voltage set points for determining the vm value (instead of buses)
• If you read in data where more than one generator on a bus that have different voltage set points, a warning is generated
• if you try to run a PF with more than one generator on a bus that have different voltage set points you get an error

The biggest change will be that in OPF (and related optimization models), these generator voltage set point values will become part of the standard solution data.

[jd-lara]

This sounds like a reasonable plan and it addresses our main concern with the pf solution

[ccoffrin]

I have opened an issue #798 to make sure this gets into the next breaking release. I propose to close this PR for now, as the proposed implementation will be quite different. I will endeavor to complete it in the next couple of weeks.

[jd-lara]

I have opened an issue #798 to make sure this gets into the next breaking release. I propose to close this PR for now, as the proposed implementation will be quite different. I will endeavor to complete it in the next couple of weeks.

Ok, I will merge the change in PSY in the meantime since we need this fix for some current work. Once 0.19 gets released we will update the code.